On Thu, Sep 4, 2008 at 8:52 PM, Benjamin Smith-Mannschott <
[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]
>> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Reply via email to