You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Benjamin Smith-Mannschott <bs...@gmail.com> on 2008/09/04 13:21:05 UTC
how, exactly, does maven compare versions
Here's what I think I've understood out of my reading and my
experimentation:
Maven's version numbers have forms like this:
major[.minor[.fix]]-[blahblahblah[-buildnr]]
Where major, minor, fix are parsed and compared as integers. Assumed
to be zero if missing?
blahblahblah is parsed and compared asciibetically. buildnr is just a
convention. one might think that it's compared numerically, but in
fact, it's not. (Maven definitive guide).
Ah, but then there are snapshots too. Can we combine some arbitrary
text (blahblahblah) with a SNAPSHOT? I don't know, but this works:
major[.minor[.fix]]-SNAPSHOT
This doesn't:
Branchname-SNAPSHOT
OtherBranchname-SNAPSHOT
(Maven seems to pay attention only to the relative newness of the
SNAPSHOT and ignore the Branchname when resolving dependencies. This
has forced my to give hard version numbers to in-development branches
earlier than I'd like to.)
The snapshot expands to something like this: 20080818.084237-2, which
seems to include a build number.
What happens when the two conflict? i.e.
20080818.010000-2 cmp? 20080818.230000-1
Is this build number also compared asciibetically? (Not that it's
likely to matter since the time stamp changes.)
So, are the following true? :
1 = 1.0.0
1 < 1.0.1
9.0.0 < 10.0.0
1.0.0 < 1.0.0-01
1.0.0 < 1.0.0-00
1.0.0-Apple-09 < 1.0.0-Zed-01
1.0.0-SNAPSHOT < 1.0.0
1.0.0-SNAPSHOT < 1.0.0-01
What about these:
1.0.0-Anteaters < 1.0.0-Zebras
1.0.1-Anteaters > 1.0.0-Zebras
SNAPSHOT < 0.0.0
Anteaters-SNAPSHOT cmp? Zebras-SNAPSHOT
I find myself flailing around more than I'd like on questions relating
to versioning. (Dependency resolution; Wether to keep my trunks as
SNAPSHOTs, and if so of what? Can the maintenance branch stay at 2.3.0-
SNAPSHOT, even though the maintenance releases 2.3.0-01 is out
already? Is this a misuse of build numbers? Should I sacrifice the
last position in the version number instead?)
What's missing for me is a rigorous understanding of how maven views
version numbers. Surely maven *has* rigorous ideas about this? It
would seem to be *the* most central concept in making maven workable.
hoping for enlightenment,
Ben
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: how, exactly, does maven compare versions
Posted by Benjamin Smith-Mannschott <bs...@gmail.com>.
On Fri, Sep 5, 2008 at 2:49 PM, Wim Deblauwe <wi...@gmail.com>
wrote:
> Hi,
>
> we have a kind of strange version mechanism, and I wonder I can
> 'translate'
> this to maven.
>
> This is how it works:
> E1.01.01
> E1.01.02
> ..
> V1.01
>
> Versions starting with E are test builds leading into the release
> (V1.01 in
> the example)
>
> Is 1.01 considered newer then 1.01-E01 for example?
>
> regards,
>
On Sep 5, 2008, at 17:14, Stephen Connolly replied:
> From my reading of the code, anything with a qualifier is older than
> anything without a qualifier
>
> thus 1.01-blah < 1.01
>
yup
<http://maven.apache.org/ref/current/maven-artifact/xref/org/apache/maven/artifact/versioning/DefaultArtifactVersion.html#96
>
Unless the qualifier happens to be purely numeric, in which case it's
a build number and this happens:
1.01 < 1.01-1
Also "V1.01" > "E1.01.02" > "E1.01.01" because maven punts on the
unexpected syntax of the version and just treats it as a string.
p.s. Does anyone know the design history of Maven's idea of version?
To a new user with no experience in the code base it seems like such a
hack, particularly when you start mixing in SNAPSHOT. (I'd be willing
to bet that SNAPSHOT wasn't in the original design and was shoehorned
in when people decided it was too much of a pain to edit the pom file
for every build.)
// Ben
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: how, exactly, does maven compare versions
Posted by Stephen Connolly <st...@gmail.com>.
>From my reading of the code, anything with a qualifier is older than
anything without a qualifier
thus 1.01-blah < 1.01
On Fri, Sep 5, 2008 at 2:49 PM, Wim Deblauwe <wi...@gmail.com> wrote:
> Hi,
>
> we have a kind of strange version mechanism, and I wonder I can 'translate'
> this to maven.
>
> This is how it works:
> E1.01.01
> E1.01.02
> ..
> V1.01
>
> Versions starting with E are test builds leading into the release (V1.01 in
> the example)
>
> Is 1.01 considered newer then 1.01-E01 for example?
>
> regards,
>
> Wim
>
> 2008/9/5 Benjamin Smith-Mannschott <bs...@gmail.com>
>
> >
> > On Sep 4, 2008, at 22:09, Stephen Connolly wrote:
> >
> > On Thu, Sep 4, 2008 at 8:52 PM, Benjamin Smith-Mannschott:
> >>
> >>> Yes. That helped, as did
> >>>
> http://docs.codehaus.org/display/MAVEN/Extending+Maven+2.0+Dependencies
> >>>
> >>> Which actually comes out and says that qualifier and build nr are
> >>> mutually
> >>> exclusive. The syntax given says this too, but I wasn't seeing it.
> >>> Another
> >>> way of looking at it, I suppose, is that everything following "1.2.3-"
> is
> >>> taken as single qualifier, which is compared numerically if it happens
> to
> >>> be
> >>> composed only of digits and otherwise compared as a string.
> >>>
> >>
> >>
> >> Yep:
> >>
> >>
> >>
> http://maven.apache.org/ref/current/maven-artifact/xref/org/apache/maven/artifact/versioning/DefaultArtifactVersion.html#155
> >>
> >>
> > Aha! thanks! I was grubbing around in the source of the 2.0.x branch
> > yesterday after I wrote my message looking for exactly this class, only I
> > didn't find it. ;-)
> >
> >
> >>> It seems that '.2.3', in the example above is optional, those parts
> taken
> >>> to be zero if missing. If any alphanumerics get mixed up in there or
> >>> about
> >>> without a separating hyphen the whole thing goes textual and is just
> >>> compared as a single string. At least that's what I understood. So
> >>> presumably, if we're comparing two version strings with eachother and
> one
> >>> is
> >>> "well formed" and the other is not, they just get compared as if they
> >>> were
> >>> both not well formed.
> >>>
> >>
> >>
> >> Nope:
> >>
> >>
> >>
> http://maven.apache.org/ref/current/maven-artifact/xref/org/apache/maven/artifact/versioning/DefaultArtifactVersion.html#54
> >>
> >> If one is treated as a string (because it's malformed) the other will
> >> always
> >> be newer (because it has a build number)
> >>
> >
> > Actually, it looks like the build number only enters into it when both
> have
> > a build number, but build number and qualifier are mutually exclusive, so
> > the logic exits early if one has a qualifier and the other doesn't.
> >
> > Somehow that logic makes me a little queezy, but at least it does appear
> to
> > sort consistently.
> >
> >
> > // Ben
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
Re: how, exactly, does maven compare versions
Posted by Wim Deblauwe <wi...@gmail.com>.
Hi,
we have a kind of strange version mechanism, and I wonder I can 'translate'
this to maven.
This is how it works:
E1.01.01
E1.01.02
..
V1.01
Versions starting with E are test builds leading into the release (V1.01 in
the example)
Is 1.01 considered newer then 1.01-E01 for example?
regards,
Wim
2008/9/5 Benjamin Smith-Mannschott <bs...@gmail.com>
>
> On Sep 4, 2008, at 22:09, Stephen Connolly wrote:
>
> On Thu, Sep 4, 2008 at 8:52 PM, Benjamin Smith-Mannschott:
>>
>>> Yes. That helped, as did
>>> http://docs.codehaus.org/display/MAVEN/Extending+Maven+2.0+Dependencies
>>>
>>> Which actually comes out and says that qualifier and build nr are
>>> mutually
>>> exclusive. The syntax given says this too, but I wasn't seeing it.
>>> Another
>>> way of looking at it, I suppose, is that everything following "1.2.3-" is
>>> taken as single qualifier, which is compared numerically if it happens to
>>> be
>>> composed only of digits and otherwise compared as a string.
>>>
>>
>>
>> Yep:
>>
>>
>> http://maven.apache.org/ref/current/maven-artifact/xref/org/apache/maven/artifact/versioning/DefaultArtifactVersion.html#155
>>
>>
> Aha! thanks! I was grubbing around in the source of the 2.0.x branch
> yesterday after I wrote my message looking for exactly this class, only I
> didn't find it. ;-)
>
>
>>> It seems that '.2.3', in the example above is optional, those parts taken
>>> to be zero if missing. If any alphanumerics get mixed up in there or
>>> about
>>> without a separating hyphen the whole thing goes textual and is just
>>> compared as a single string. At least that's what I understood. So
>>> presumably, if we're comparing two version strings with eachother and one
>>> is
>>> "well formed" and the other is not, they just get compared as if they
>>> were
>>> both not well formed.
>>>
>>
>>
>> Nope:
>>
>>
>> http://maven.apache.org/ref/current/maven-artifact/xref/org/apache/maven/artifact/versioning/DefaultArtifactVersion.html#54
>>
>> If one is treated as a string (because it's malformed) the other will
>> always
>> be newer (because it has a build number)
>>
>
> Actually, it looks like the build number only enters into it when both have
> a build number, but build number and qualifier are mutually exclusive, so
> the logic exits early if one has a qualifier and the other doesn't.
>
> Somehow that logic makes me a little queezy, but at least it does appear to
> sort consistently.
>
>
> // Ben
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: how, exactly, does maven compare versions
Posted by Benjamin Smith-Mannschott <bs...@gmail.com>.
On Sep 4, 2008, at 22:09, Stephen Connolly wrote:
> On Thu, Sep 4, 2008 at 8:52 PM, Benjamin Smith-Mannschott:
>> Yes. That helped, as did
>> http://docs.codehaus.org/display/MAVEN/Extending+Maven+2.0+Dependencies
>>
>> Which actually comes out and says that qualifier and build nr are
>> mutually
>> exclusive. The syntax given says this too, but I wasn't seeing it.
>> Another
>> way of looking at it, I suppose, is that everything following
>> "1.2.3-" is
>> taken as single qualifier, which is compared numerically if it
>> happens to be
>> composed only of digits and otherwise compared as a string.
>
>
> Yep:
>
> http://maven.apache.org/ref/current/maven-artifact/xref/org/apache/maven/artifact/versioning/DefaultArtifactVersion.html#155
>
Aha! thanks! I was grubbing around in the source of the 2.0.x branch
yesterday after I wrote my message looking for exactly this class,
only I didn't find it. ;-)
>>
>> It seems that '.2.3', in the example above is optional, those parts
>> taken
>> to be zero if missing. If any alphanumerics get mixed up in there
>> or about
>> without a separating hyphen the whole thing goes textual and is just
>> compared as a single string. At least that's what I understood. So
>> presumably, if we're comparing two version strings with eachother
>> and one is
>> "well formed" and the other is not, they just get compared as if
>> they were
>> both not well formed.
>
>
> Nope:
>
> http://maven.apache.org/ref/current/maven-artifact/xref/org/apache/maven/artifact/versioning/DefaultArtifactVersion.html#54
>
> If one is treated as a string (because it's malformed) the other
> will always
> be newer (because it has a build number)
Actually, it looks like the build number only enters into it when both
have a build number, but build number and qualifier are mutually
exclusive, so the logic exits early if one has a qualifier and the
other doesn't.
Somehow that logic makes me a little queezy, but at least it does
appear to sort consistently.
// Ben
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: how, exactly, does maven compare versions
Posted by Stephen Connolly <st...@gmail.com>.
On Thu, Sep 4, 2008 at 8:52 PM, Benjamin Smith-Mannschott <
bsmith.occs@gmail.com> wrote:
>
> On Sep 4, 2008, at 18:47, Beyer,Nathan wrote:
>
> Have you read this document -
>> http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution
>>
>> It may help answer some of the questions.
>>
>>
> Yes. That helped, as did
> http://docs.codehaus.org/display/MAVEN/Extending+Maven+2.0+Dependencies
>
> Which actually comes out and says that qualifier and build nr are mutually
> exclusive. The syntax given says this too, but I wasn't seeing it. Another
> way of looking at it, I suppose, is that everything following "1.2.3-" is
> taken as single qualifier, which is compared numerically if it happens to be
> composed only of digits and otherwise compared as a string.
Yep:
http://maven.apache.org/ref/current/maven-artifact/xref/org/apache/maven/artifact/versioning/DefaultArtifactVersion.html#155
>
> It seems that '.2.3', in the example above is optional, those parts taken
> to be zero if missing. If any alphanumerics get mixed up in there or about
> without a separating hyphen the whole thing goes textual and is just
> compared as a single string. At least that's what I understood. So
> presumably, if we're comparing two version strings with eachother and one is
> "well formed" and the other is not, they just get compared as if they were
> both not well formed.
Nope:
http://maven.apache.org/ref/current/maven-artifact/xref/org/apache/maven/artifact/versioning/DefaultArtifactVersion.html#54
If one is treated as a string (because it's malformed) the other will always
be newer (because it has a build number)
>
>
> also interesting that the stirng comparison is case insensitive.
>
>
>> -----Original Message-----
>> From: Benjamin Smith-Mannschott [mailto:bsmith.occs@gmail.com]
>> Sent: Thursday, September 04, 2008 6:21 AM
>> To: Maven Users List
>> Subject: how, exactly, does maven compare versions
>>
>>
> [...snip...]
>
> From what I've read, this is what i'm guessing in answer to my own
> examples:
>
> 20080818.010000-2 cmp? 20080818.230000-1
>>
> 20080818.010000-2 < 20080818.230000-1
> because both are compared asciibetically
>
> Is this build number also compared asciibetically? (Not that it's
>> likely to matter since the time stamp changes.)
>>
>
> (it seems so, yes)
>
> So, are the following true? :
>>
>> 1 = 1.0.0
>>
> true
>
>
>> 1 < 1.0.1
>>
> true
>
>
>> 9.0.0 < 10.0.0
>>
> true
>
>
>> 1.0.0 < 1.0.0-01
>>
> Unsure, is the integer 1 compared to the integer 0, or is "01" treated as a
> sting because 1.0.0 doesn't have a comparable build number. Either way, I
> suspect "true".
>
> 1.0.0 < 1.0.0-00
>>
> ?
>
> 1.0.0-Apple-09 < 1.0.0-Zed-01
>>
> true. The whole qualifier Apple-09 or Zed-01 is compared asciibetically.
>
>>
>>
> 1.0.0-SNAPSHOT < 1.0.0
>>
> true. snapshot always before corresponding release.
>
> 1.0.0-SNAPSHOT < 1.0.0-01
>>
> This must be true, otherwise ordering is inconsistent.
>
>
> What about these:
>>
>> 1.0.0-Anteaters < 1.0.0-Zebras
>>
> true
>
> 1.0.1-Anteaters > 1.0.0-Zebras
>>
> true
>
> SNAPSHOT < 0.0.0
>>
> false? because asciibetical comparison is forced.
>
>
>> Anteaters-SNAPSHOT cmp? Zebras-SNAPSHOT
>>
>
> No idea. but I've observed what appeared to be
> Anteaters-SNAPSHOT2 > Zebras-SNAPSHOT1 when SNAPSHOT2 > SNAPSHOT1.
> I don't know why.
>
> // Ben
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: how, exactly, does maven compare versions
Posted by Benjamin Smith-Mannschott <bs...@gmail.com>.
On Sep 4, 2008, at 18:47, Beyer,Nathan wrote:
> Have you read this document - http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution
>
> It may help answer some of the questions.
>
Yes. That helped, as did
http://docs.codehaus.org/display/MAVEN/Extending+Maven+2.0+Dependencies
Which actually comes out and says that qualifier and build nr are
mutually exclusive. The syntax given says this too, but I wasn't
seeing it. Another way of looking at it, I suppose, is that everything
following "1.2.3-" is taken as single qualifier, which is compared
numerically if it happens to be composed only of digits and otherwise
compared as a string.
It seems that '.2.3', in the example above is optional, those parts
taken to be zero if missing. If any alphanumerics get mixed up in
there or about without a separating hyphen the whole thing goes
textual and is just compared as a single string. At least that's what
I understood. So presumably, if we're comparing two version strings
with eachother and one is "well formed" and the other is not, they
just get compared as if they were both not well formed.
also interesting that the stirng comparison is case insensitive.
>
> -----Original Message-----
> From: Benjamin Smith-Mannschott [mailto:bsmith.occs@gmail.com]
> Sent: Thursday, September 04, 2008 6:21 AM
> To: Maven Users List
> Subject: how, exactly, does maven compare versions
>
[...snip...]
From what I've read, this is what i'm guessing in answer to my own
examples:
> 20080818.010000-2 cmp? 20080818.230000-1
20080818.010000-2 < 20080818.230000-1
because both are compared asciibetically
> Is this build number also compared asciibetically? (Not that it's
> likely to matter since the time stamp changes.)
(it seems so, yes)
> So, are the following true? :
>
> 1 = 1.0.0
true
>
> 1 < 1.0.1
true
>
> 9.0.0 < 10.0.0
true
>
> 1.0.0 < 1.0.0-01
Unsure, is the integer 1 compared to the integer 0, or is "01" treated
as a sting because 1.0.0 doesn't have a comparable build number.
Either way, I suspect "true".
> 1.0.0 < 1.0.0-00
?
> 1.0.0-Apple-09 < 1.0.0-Zed-01
true. The whole qualifier Apple-09 or Zed-01 is compared asciibetically.
>
> 1.0.0-SNAPSHOT < 1.0.0
true. snapshot always before corresponding release.
> 1.0.0-SNAPSHOT < 1.0.0-01
This must be true, otherwise ordering is inconsistent.
> What about these:
>
> 1.0.0-Anteaters < 1.0.0-Zebras
true
> 1.0.1-Anteaters > 1.0.0-Zebras
true
> SNAPSHOT < 0.0.0
false? because asciibetical comparison is forced.
>
> Anteaters-SNAPSHOT cmp? Zebras-SNAPSHOT
No idea. but I've observed what appeared to be
Anteaters-SNAPSHOT2 > Zebras-SNAPSHOT1 when SNAPSHOT2 > SNAPSHOT1.
I don't know why.
// Ben
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: how, exactly, does maven compare versions
Posted by "Beyer,Nathan" <NB...@CERNER.COM>.
Have you read this document - http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution
It may help answer some of the questions.
-----Original Message-----
From: Benjamin Smith-Mannschott [mailto:bsmith.occs@gmail.com]
Sent: Thursday, September 04, 2008 6:21 AM
To: Maven Users List
Subject: how, exactly, does maven compare versions
Here's what I think I've understood out of my reading and my
experimentation:
Maven's version numbers have forms like this:
major[.minor[.fix]]-[blahblahblah[-buildnr]]
Where major, minor, fix are parsed and compared as integers. Assumed
to be zero if missing?
blahblahblah is parsed and compared asciibetically. buildnr is just a
convention. one might think that it's compared numerically, but in
fact, it's not. (Maven definitive guide).
Ah, but then there are snapshots too. Can we combine some arbitrary
text (blahblahblah) with a SNAPSHOT? I don't know, but this works:
major[.minor[.fix]]-SNAPSHOT
This doesn't:
Branchname-SNAPSHOT
OtherBranchname-SNAPSHOT
(Maven seems to pay attention only to the relative newness of the
SNAPSHOT and ignore the Branchname when resolving dependencies. This
has forced my to give hard version numbers to in-development branches
earlier than I'd like to.)
The snapshot expands to something like this: 20080818.084237-2, which
seems to include a build number.
What happens when the two conflict? i.e.
20080818.010000-2 cmp? 20080818.230000-1
Is this build number also compared asciibetically? (Not that it's
likely to matter since the time stamp changes.)
So, are the following true? :
1 = 1.0.0
1 < 1.0.1
9.0.0 < 10.0.0
1.0.0 < 1.0.0-01
1.0.0 < 1.0.0-00
1.0.0-Apple-09 < 1.0.0-Zed-01
1.0.0-SNAPSHOT < 1.0.0
1.0.0-SNAPSHOT < 1.0.0-01
What about these:
1.0.0-Anteaters < 1.0.0-Zebras
1.0.1-Anteaters > 1.0.0-Zebras
SNAPSHOT < 0.0.0
Anteaters-SNAPSHOT cmp? Zebras-SNAPSHOT
I find myself flailing around more than I'd like on questions relating
to versioning. (Dependency resolution; Wether to keep my trunks as
SNAPSHOTs, and if so of what? Can the maintenance branch stay at 2.3.0-
SNAPSHOT, even though the maintenance releases 2.3.0-01 is out
already? Is this a misuse of build numbers? Should I sacrifice the
last position in the version number instead?)
What's missing for me is a rigorous understanding of how maven views
version numbers. Surely maven *has* rigorous ideas about this? It
would seem to be *the* most central concept in making maven workable.
hoping for enlightenment,
Ben
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
----------------------------------------------------------------------
CONFIDENTIALITY NOTICE This message and any included attachments are from Cerner Corporation and are intended only for the addressee. The information contained in this message is confidential and may constitute inside or non-public information under international, federal, or state securities laws. Unauthorized forwarding, printing, copying, distribution, or use of such information is strictly prohibited and may be unlawful. If you are not the addressee, please promptly delete this message and notify the sender of the delivery error by e-mail or you may call Cerner's corporate offices in Kansas City, Missouri, U.S.A at (+1) (816)221-1024.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org