You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Ross Goldberg <ro...@gmail.com> on 2018/05/31 14:22:18 UTC
Maven version order spec weirdness
The maven Maven version order spec (
https://maven.apache.org/pom.html#Version_Order_Specification) indicates
that :
1-0-2 is equivalent to 1-2, so 1-0-2 = 1-2 > 1-1.
That doesn't make much sense to me.
I think the following line from the spec should be revised from:
Then, starting from the end of the version, the trailing "null" values (0,
"", "final", "ga") are trimmed.
To:
Then, starting from the end of the version string, all trailing "null"
qualifier tokens ("", "final", "ga") are trimmed. All trailing numeric 0
tokens that do not immediately follow a hyphen prefix (regardless of
whether the hyphen is explicit or implicit) are likewise trimmed.
Re: Maven version order spec weirdness
Posted by Ross Goldberg <ro...@gmail.com>.
I’m amending my proposal to be:
Then, starting from the end of the version string, the following trailing
"null" tokens are trimmed:
* “null” qualifier tokens ("", "final", "ga")
* 0 tokens, except for those that are sandwiched between two hyphens
with a numeric token immediately following the latter hyphen. Thus, e.g.:
1.-0.0-20 -> 1-0-20
1-0-rc-2 -> 1-rc-2
On Thu, May 31, 2018 at 10:22 AM Ross Goldberg <ro...@gmail.com>
wrote:
> The maven Maven version order spec (
> https://maven.apache.org/pom.html#Version_Order_Specification) indicates
> that :
>
> 1-0-2 is equivalent to 1-2, so 1-0-2 = 1-2 > 1-1.
>
> That doesn't make much sense to me.
>
> I think the following line from the spec should be revised from:
>
> Then, starting from the end of the version, the trailing "null" values (0,
> "", "final", "ga") are trimmed.
>
> To:
>
> Then, starting from the end of the version string, all trailing "null"
> qualifier tokens ("", "final", "ga") are trimmed. All trailing numeric 0
> tokens that do not immediately follow a hyphen prefix (regardless of
> whether the hyphen is explicit or implicit) are likewise trimmed.
>
Re: Maven version order spec weirdness
Posted by Ross Goldberg <ro...@gmail.com>.
If you step through the algorithm from the spec, and if you run the main
method from ComparableVersion, you’ll see that the canonical form for 1-0-2
is indeed 1-2. There are places where the code deviates from the spec, for
which I’ve filed a bug report, but this is not one of them.
Does whoever is in charge of the spec intend for 1-0-2 > 1-1?
If yes, then we can discuss the merits of the two different orderings, and
the spec lead can decide whatever they want (that spec lead might be you,
but it certainly isn’t me, so I know I don’t have any decision-making
authority).
If no, then the code is definitely wrong, and must be fixed. We can then
look through the spec & determine if the spec needs to be revised, and, if
it must, determine the best way to revise it.
On Fri, Jun 1, 2018 at 6:33 PM Robert Scholte <rf...@apache.org> wrote:
> IIRC only digits between dots are interpreted as numbers and will be
> compared as numbers
> With dashes values are concatenated as a String and hence will be
> compared
> as Strings.
> So dots and dashes have a different effect.
>
> Here you can find a huge number of tests that should cover it:
>
> https://maven.apache.org/resolver/maven-resolver-util/xref-test/org/eclipse/aether/util/version/GenericVersionTest.html
>
> Robert
>
> On Sat, 02 Jun 2018 00:12:57 +0200, Ross Goldberg
> <ro...@gmail.com> wrote:
>
> > Sorry, I didn’t mean that the spec explicitly states an example that:
> >
> > 1-0-2 = 1-2 > 1-1
> >
> > I meant that the algorithm described in the spec results in that outcome.
> > ComparableVersion correctly outputs that for the comparison between
> > 1-0-2 &
> > 1-1.
> >
> > Both my original & my revised proposed change to the spec would result
> > in:
> >
> > 1-0-2 = 1-0-2 < 1-1
> >
> > Which I think makes more sense.
> >
> > My original proposal would have resulted in:
> >
> > 1-0-rc = 1-0-rc
> >
> > But my revised proposal results in:
> >
> > 1-0-rc = 1-rc
> >
> > Which accords with the existing spec, so my revised proposal improves
> > upon
> > my original proposal.
> >
> > Throughout this email, the syntax for = is:
> >
> > original = canonical
> >
> > On Fri, Jun 1, 2018 at 5:34 PM Robert Scholte <rf...@apache.org>
> > wrote:
> >
> >> On Thu, 31 May 2018 16:22:18 +0200, Ross Goldberg
> >> <ro...@gmail.com> wrote:
> >>
> >> > The maven Maven version order spec (
> >> > https://maven.apache.org/pom.html#Version_Order_Specification)
> >> indicates
> >> > that :
> >> >
> >> > 1-0-2 is equivalent to 1-2, so 1-0-2 = 1-2 > 1-1.
> >>
> >> I don't recognize this. Can you quote from that page?
> >>
> >> Robert
> >>
> >> >
> >> > That doesn't make much sense to me.
> >> >
> >> > I think the following line from the spec should be revised from:
> >> >
> >> > Then, starting from the end of the version, the trailing "null" values
> >> > (0,
> >> > "", "final", "ga") are trimmed.
> >> >
> >> > To:
> >> >
> >> > Then, starting from the end of the version string, all trailing "null"
> >> > qualifier tokens ("", "final", "ga") are trimmed. All trailing
> >> numeric 0
> >> > tokens that do not immediately follow a hyphen prefix (regardless of
> >> > whether the hyphen is explicit or implicit) are likewise trimmed.
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Maven version order spec weirdness
Posted by Robert Scholte <rf...@apache.org>.
IIRC only digits between dots are interpreted as numbers and will be
compared as numbers
With dashes values are concatenated as a String and hence will be compared
as Strings.
So dots and dashes have a different effect.
Here you can find a huge number of tests that should cover it:
https://maven.apache.org/resolver/maven-resolver-util/xref-test/org/eclipse/aether/util/version/GenericVersionTest.html
Robert
On Sat, 02 Jun 2018 00:12:57 +0200, Ross Goldberg
<ro...@gmail.com> wrote:
> Sorry, I didn’t mean that the spec explicitly states an example that:
>
> 1-0-2 = 1-2 > 1-1
>
> I meant that the algorithm described in the spec results in that outcome.
> ComparableVersion correctly outputs that for the comparison between
> 1-0-2 &
> 1-1.
>
> Both my original & my revised proposed change to the spec would result
> in:
>
> 1-0-2 = 1-0-2 < 1-1
>
> Which I think makes more sense.
>
> My original proposal would have resulted in:
>
> 1-0-rc = 1-0-rc
>
> But my revised proposal results in:
>
> 1-0-rc = 1-rc
>
> Which accords with the existing spec, so my revised proposal improves
> upon
> my original proposal.
>
> Throughout this email, the syntax for = is:
>
> original = canonical
>
> On Fri, Jun 1, 2018 at 5:34 PM Robert Scholte <rf...@apache.org>
> wrote:
>
>> On Thu, 31 May 2018 16:22:18 +0200, Ross Goldberg
>> <ro...@gmail.com> wrote:
>>
>> > The maven Maven version order spec (
>> > https://maven.apache.org/pom.html#Version_Order_Specification)
>> indicates
>> > that :
>> >
>> > 1-0-2 is equivalent to 1-2, so 1-0-2 = 1-2 > 1-1.
>>
>> I don't recognize this. Can you quote from that page?
>>
>> Robert
>>
>> >
>> > That doesn't make much sense to me.
>> >
>> > I think the following line from the spec should be revised from:
>> >
>> > Then, starting from the end of the version, the trailing "null" values
>> > (0,
>> > "", "final", "ga") are trimmed.
>> >
>> > To:
>> >
>> > Then, starting from the end of the version string, all trailing "null"
>> > qualifier tokens ("", "final", "ga") are trimmed. All trailing
>> numeric 0
>> > tokens that do not immediately follow a hyphen prefix (regardless of
>> > whether the hyphen is explicit or implicit) are likewise trimmed.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven version order spec weirdness
Posted by Ross Goldberg <ro...@gmail.com>.
Sorry, I didn’t mean that the spec explicitly states an example that:
1-0-2 = 1-2 > 1-1
I meant that the algorithm described in the spec results in that outcome.
ComparableVersion correctly outputs that for the comparison between 1-0-2 &
1-1.
Both my original & my revised proposed change to the spec would result in:
1-0-2 = 1-0-2 < 1-1
Which I think makes more sense.
My original proposal would have resulted in:
1-0-rc = 1-0-rc
But my revised proposal results in:
1-0-rc = 1-rc
Which accords with the existing spec, so my revised proposal improves upon
my original proposal.
Throughout this email, the syntax for = is:
original = canonical
On Fri, Jun 1, 2018 at 5:34 PM Robert Scholte <rf...@apache.org> wrote:
> On Thu, 31 May 2018 16:22:18 +0200, Ross Goldberg
> <ro...@gmail.com> wrote:
>
> > The maven Maven version order spec (
> > https://maven.apache.org/pom.html#Version_Order_Specification) indicates
> > that :
> >
> > 1-0-2 is equivalent to 1-2, so 1-0-2 = 1-2 > 1-1.
>
> I don't recognize this. Can you quote from that page?
>
> Robert
>
> >
> > That doesn't make much sense to me.
> >
> > I think the following line from the spec should be revised from:
> >
> > Then, starting from the end of the version, the trailing "null" values
> > (0,
> > "", "final", "ga") are trimmed.
> >
> > To:
> >
> > Then, starting from the end of the version string, all trailing "null"
> > qualifier tokens ("", "final", "ga") are trimmed. All trailing numeric 0
> > tokens that do not immediately follow a hyphen prefix (regardless of
> > whether the hyphen is explicit or implicit) are likewise trimmed.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Maven version order spec weirdness
Posted by Robert Scholte <rf...@apache.org>.
On Thu, 31 May 2018 16:22:18 +0200, Ross Goldberg
<ro...@gmail.com> wrote:
> The maven Maven version order spec (
> https://maven.apache.org/pom.html#Version_Order_Specification) indicates
> that :
>
> 1-0-2 is equivalent to 1-2, so 1-0-2 = 1-2 > 1-1.
I don't recognize this. Can you quote from that page?
Robert
>
> That doesn't make much sense to me.
>
> I think the following line from the spec should be revised from:
>
> Then, starting from the end of the version, the trailing "null" values
> (0,
> "", "final", "ga") are trimmed.
>
> To:
>
> Then, starting from the end of the version string, all trailing "null"
> qualifier tokens ("", "final", "ga") are trimmed. All trailing numeric 0
> tokens that do not immediately follow a hyphen prefix (regardless of
> whether the hyphen is explicit or implicit) are likewise trimmed.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven version order spec weirdness
Posted by Hervé BOUTEMY <he...@free.fr>.
what you are discovering is that the ordering is not complete: it's not
intended to be a full "spec" that can compare anything
it's intended as a way to try to compare cases found in reality by people who
really chose a sequence of versions for their artifacts, without putting more
constraints on the way to write version strings than just common sense
Regards,
Hervé
Le dimanche 3 juin 2018 07:37:30 CEST, vous avez écrit :
> The spec also seems to not define the comparison output for when two tokens
> have the same prefix, but one token is a qualifier, and the other is an
> integer:
>
> For such cases, the ComparableVersion code behaves oddly, in that it
> outputs:
>
> java -jar maven-artifact-3.5.3.jar 2 2.a
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 2 == 2
> 2 < 2.a
> 2. 2.a == 2.a
>
> java -jar maven-artifact-3.5.3.jar 2.0.a 2.a
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 2.0.a == 2.0.a
> 2.0.a > 2.a
> 2. 2.a == 2.a
>
> Why is:
>
> 2 == 2.0 == 2.0.0 < 2.a == 2.a.0 < 2.0.a
>
> That doesn't make much sense to me. I would normally expect a to be
> consistently higher than 0 (except for the special a<integer> alpha
> replacement, which isn't apropos to this example):
>
> 2 == 2.0 == 2.0.0 < 2.0.a < 2.a == 2.a.0
>
> If you must have 2.a.0 < 2.0.a, then I would expect a to consistently be
> lower than 0:
>
> 2.a == 2.a.0 < 2.0.a < 2 == 2.0 == 2.0.0
>
> I think you could obtain my preferred ordering by rewriting the "prefixed
> token order" segment of the spec as the following (I haven't thought it
> through completely, though, so there might be bugs):
>
> - if the prefix is the same, then compare the tokens using the following
> ordering scheme:
>
> "alpha" < "beta" < "milestone" < "rc" = "cr" < "snapshot" < "" =
> "final" = "ga" = 0 < "sp" < all other qualifiers in alphabetical order <
> positive integers in natural order
>
> the "alpha", "beta" and "milestone" qualifiers can respectively be
> shortened to "a", "b" and "m" when directly followed by a number.
>
> - else .qualifier < -token < .integer
>
>
>
> In the above, you could elongate the last line to:
>
> - else .qualifier < -qualifier < -integer < .integer
>
>
>
> On Sat, Jun 2, 2018 at 11:37 AM, Ross Goldberg <ro...@gmail.com>
>
> wrote:
> > Sorry, the 1-0-2 == 1-2 induced me to read the < as a >.
> >
> > The code is buggy because it produces a canonical form & a comparison
> > result that are inconsistent.
> >
> > The canonical form is consistent with the spec (as I read the spec; if you
> > read it otherwise, please let me know).
> >
> > Everything should be consistent, otherwise, things will break & people
> > won't know what to expect.
> >
> > e.g., ComparableVersion#equals(Object o) uses canonical.equals(((
> > ComparableVersion) o).canonical). This breaks the Comparable contract,
> > since:
> >
> > true == new ComparableVersion("1-0-2").equals(new ComparableVersion("1-2")
> > )
> >
> > But:
> >
> > -1 == new ComparableVersion("1-0-2").compareTo(new ComparableVersi
> > on("1-2"))
> >
> > Given that breaking the Comparable contract is bad, the code should
> > probably be made consistent.
> >
> > If you modify the code, you might as well choose the outcome that would
> > make the most sense to most people.
> >
> > Most people would expect the current ordering (1-0-2 < 1-1), but not the
> > current canonical form for 1-0-2 (1-2).
> >
> > Therefore, it makes sense to me to change the canonical form and to keep
> > the current ordering.
> >
> > If you do this, then the code will not reflect the spec (as I read the
> > spec).
> >
> > I feel that my revised proposal aligns the spec with the current ordering.
> >
> > On Sat, Jun 2, 2018 at 4:59 AM, Hervé BOUTEMY <he...@free.fr>
> >
> > wrote:
> >> no, current implementation result is 1-0-2 < 1-1
> >>
> >> here is the proof:
> >> $ java -jar maven-artifact-3.5.3.jar 1-0-2 1-1
> >> Display parameters as parsed by Maven (in canonical form) and comparison
> >> result:
> >> 1. 1-0-2 == 1-2
> >>
> >> 1-0-2 < 1-1
> >>
> >> 2. 1-1 == 1-1
> >>
> >>
> >> then explanations: who uses dashes (-) instead of dots (.) as version
> >> separator?
> >> dash is not a normal version separator in Maven: it's used to as a
> >> separator between version and qualifier
> >> then 1-0-2 is something that we don't really understand: 1.0-2 or 1.0.2
> >> would have a meaning, but not 1-0-2
> >>
> >> Then honestly, I won't even try to understand how we got to the
> >> conclusion that 1-0-2 canonical representation is 1-2: I'd question
> >> people
> >> who wrote 1-0-2 as version string
> >>
> >> Regards,
> >>
> >> Hervé
> >>
> >> Le jeudi 31 mai 2018, 16:22:18 CEST Ross Goldberg a écrit :
> >> > The maven Maven version order spec (
> >> > https://maven.apache.org/pom.html#Version_Order_Specification)
> >>
> >> indicates
> >>
> >> > that :
> >> >
> >> > 1-0-2 is equivalent to 1-2, so 1-0-2 = 1-2 > 1-1.
> >> >
> >> > That doesn't make much sense to me.
> >> >
> >> > I think the following line from the spec should be revised from:
> >> >
> >> > Then, starting from the end of the version, the trailing "null" values
> >>
> >> (0,
> >>
> >> > "", "final", "ga") are trimmed.
> >> >
> >> > To:
> >> >
> >> > Then, starting from the end of the version string, all trailing "null"
> >> > qualifier tokens ("", "final", "ga") are trimmed. All trailing numeric
> >> > 0
> >> > tokens that do not immediately follow a hyphen prefix (regardless of
> >> > whether the hyphen is explicit or implicit) are likewise trimmed.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven version order spec weirdness
Posted by Ross Goldberg <ro...@gmail.com>.
The spec also seems to not define the comparison output for when two tokens
have the same prefix, but one token is a qualifier, and the other is an
integer:
For such cases, the ComparableVersion code behaves oddly, in that it
outputs:
java -jar maven-artifact-3.5.3.jar 2 2.a
Display parameters as parsed by Maven (in canonical form) and comparison
result:
1. 2 == 2
2 < 2.a
2. 2.a == 2.a
java -jar maven-artifact-3.5.3.jar 2.0.a 2.a
Display parameters as parsed by Maven (in canonical form) and comparison
result:
1. 2.0.a == 2.0.a
2.0.a > 2.a
2. 2.a == 2.a
Why is:
2 == 2.0 == 2.0.0 < 2.a == 2.a.0 < 2.0.a
That doesn't make much sense to me. I would normally expect a to be
consistently higher than 0 (except for the special a<integer> alpha
replacement, which isn't apropos to this example):
2 == 2.0 == 2.0.0 < 2.0.a < 2.a == 2.a.0
If you must have 2.a.0 < 2.0.a, then I would expect a to consistently be
lower than 0:
2.a == 2.a.0 < 2.0.a < 2 == 2.0 == 2.0.0
I think you could obtain my preferred ordering by rewriting the "prefixed
token order" segment of the spec as the following (I haven't thought it
through completely, though, so there might be bugs):
- if the prefix is the same, then compare the tokens using the following
ordering scheme:
"alpha" < "beta" < "milestone" < "rc" = "cr" < "snapshot" < "" =
"final" = "ga" = 0 < "sp" < all other qualifiers in alphabetical order <
positive integers in natural order
the "alpha", "beta" and "milestone" qualifiers can respectively be
shortened to "a", "b" and "m" when directly followed by a number.
- else .qualifier < -token < .integer
In the above, you could elongate the last line to:
- else .qualifier < -qualifier < -integer < .integer
On Sat, Jun 2, 2018 at 11:37 AM, Ross Goldberg <ro...@gmail.com>
wrote:
> Sorry, the 1-0-2 == 1-2 induced me to read the < as a >.
>
> The code is buggy because it produces a canonical form & a comparison
> result that are inconsistent.
>
> The canonical form is consistent with the spec (as I read the spec; if you
> read it otherwise, please let me know).
>
> Everything should be consistent, otherwise, things will break & people
> won't know what to expect.
>
> e.g., ComparableVersion#equals(Object o) uses canonical.equals(((
> ComparableVersion) o).canonical). This breaks the Comparable contract,
> since:
>
> true == new ComparableVersion("1-0-2").equals(new ComparableVersion("1-2")
> )
>
> But:
>
> -1 == new ComparableVersion("1-0-2").compareTo(new ComparableVersi
> on("1-2"))
>
> Given that breaking the Comparable contract is bad, the code should
> probably be made consistent.
>
> If you modify the code, you might as well choose the outcome that would
> make the most sense to most people.
>
> Most people would expect the current ordering (1-0-2 < 1-1), but not the
> current canonical form for 1-0-2 (1-2).
>
> Therefore, it makes sense to me to change the canonical form and to keep
> the current ordering.
>
> If you do this, then the code will not reflect the spec (as I read the
> spec).
>
> I feel that my revised proposal aligns the spec with the current ordering.
>
> On Sat, Jun 2, 2018 at 4:59 AM, Hervé BOUTEMY <he...@free.fr>
> wrote:
>
>> no, current implementation result is 1-0-2 < 1-1
>>
>> here is the proof:
>> $ java -jar maven-artifact-3.5.3.jar 1-0-2 1-1
>> Display parameters as parsed by Maven (in canonical form) and comparison
>> result:
>> 1. 1-0-2 == 1-2
>> 1-0-2 < 1-1
>> 2. 1-1 == 1-1
>>
>>
>> then explanations: who uses dashes (-) instead of dots (.) as version
>> separator?
>> dash is not a normal version separator in Maven: it's used to as a
>> separator between version and qualifier
>> then 1-0-2 is something that we don't really understand: 1.0-2 or 1.0.2
>> would have a meaning, but not 1-0-2
>>
>> Then honestly, I won't even try to understand how we got to the
>> conclusion that 1-0-2 canonical representation is 1-2: I'd question people
>> who wrote 1-0-2 as version string
>>
>> Regards,
>>
>> Hervé
>>
>> Le jeudi 31 mai 2018, 16:22:18 CEST Ross Goldberg a écrit :
>> > The maven Maven version order spec (
>> > https://maven.apache.org/pom.html#Version_Order_Specification)
>> indicates
>> > that :
>> >
>> > 1-0-2 is equivalent to 1-2, so 1-0-2 = 1-2 > 1-1.
>> >
>> > That doesn't make much sense to me.
>> >
>> > I think the following line from the spec should be revised from:
>> >
>> > Then, starting from the end of the version, the trailing "null" values
>> (0,
>> > "", "final", "ga") are trimmed.
>> >
>> > To:
>> >
>> > Then, starting from the end of the version string, all trailing "null"
>> > qualifier tokens ("", "final", "ga") are trimmed. All trailing numeric 0
>> > tokens that do not immediately follow a hyphen prefix (regardless of
>> > whether the hyphen is explicit or implicit) are likewise trimmed.
>>
>
Re: Maven version order spec weirdness
Posted by Ross Goldberg <ro...@gmail.com>.
Sorry, the 1-0-2 == 1-2 induced me to read the < as a >.
The code is buggy because it produces a canonical form & a comparison
result that are inconsistent.
The canonical form is consistent with the spec (as I read the spec; if you
read it otherwise, please let me know).
Everything should be consistent, otherwise, things will break & people
won't know what to expect.
e.g., ComparableVersion#equals(Object o) uses canonical.equals(((
ComparableVersion) o).canonical). This breaks the Comparable contract,
since:
true == new ComparableVersion("1-0-2").equals(new ComparableVersion("1-2"))
But:
-1 == new ComparableVersion("1-0-2").compareTo(new ComparableVersion("1-2"))
Given that breaking the Comparable contract is bad, the code should
probably be made consistent.
If you modify the code, you might as well choose the outcome that would
make the most sense to most people.
Most people would expect the current ordering (1-0-2 < 1-1), but not the
current canonical form for 1-0-2 (1-2).
Therefore, it makes sense to me to change the canonical form and to keep
the current ordering.
If you do this, then the code will not reflect the spec (as I read the
spec).
I feel that my revised proposal aligns the spec with the current ordering.
On Sat, Jun 2, 2018 at 4:59 AM, Hervé BOUTEMY <he...@free.fr> wrote:
> no, current implementation result is 1-0-2 < 1-1
>
> here is the proof:
> $ java -jar maven-artifact-3.5.3.jar 1-0-2 1-1
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0-2 == 1-2
> 1-0-2 < 1-1
> 2. 1-1 == 1-1
>
>
> then explanations: who uses dashes (-) instead of dots (.) as version
> separator?
> dash is not a normal version separator in Maven: it's used to as a
> separator between version and qualifier
> then 1-0-2 is something that we don't really understand: 1.0-2 or 1.0.2
> would have a meaning, but not 1-0-2
>
> Then honestly, I won't even try to understand how we got to the conclusion
> that 1-0-2 canonical representation is 1-2: I'd question people who wrote
> 1-0-2 as version string
>
> Regards,
>
> Hervé
>
> Le jeudi 31 mai 2018, 16:22:18 CEST Ross Goldberg a écrit :
> > The maven Maven version order spec (
> > https://maven.apache.org/pom.html#Version_Order_Specification) indicates
> > that :
> >
> > 1-0-2 is equivalent to 1-2, so 1-0-2 = 1-2 > 1-1.
> >
> > That doesn't make much sense to me.
> >
> > I think the following line from the spec should be revised from:
> >
> > Then, starting from the end of the version, the trailing "null" values
> (0,
> > "", "final", "ga") are trimmed.
> >
> > To:
> >
> > Then, starting from the end of the version string, all trailing "null"
> > qualifier tokens ("", "final", "ga") are trimmed. All trailing numeric 0
> > tokens that do not immediately follow a hyphen prefix (regardless of
> > whether the hyphen is explicit or implicit) are likewise trimmed.
>
Re: Maven version order spec weirdness
Posted by Hervé BOUTEMY <he...@free.fr>.
no, current implementation result is 1-0-2 < 1-1
here is the proof:
$ java -jar maven-artifact-3.5.3.jar 1-0-2 1-1
Display parameters as parsed by Maven (in canonical form) and comparison result:
1. 1-0-2 == 1-2
1-0-2 < 1-1
2. 1-1 == 1-1
then explanations: who uses dashes (-) instead of dots (.) as version separator?
dash is not a normal version separator in Maven: it's used to as a separator between version and qualifier
then 1-0-2 is something that we don't really understand: 1.0-2 or 1.0.2 would have a meaning, but not 1-0-2
Then honestly, I won't even try to understand how we got to the conclusion that 1-0-2 canonical representation is 1-2: I'd question people who wrote 1-0-2 as version string
Regards,
Hervé
Le jeudi 31 mai 2018, 16:22:18 CEST Ross Goldberg a écrit :
> The maven Maven version order spec (
> https://maven.apache.org/pom.html#Version_Order_Specification) indicates
> that :
>
> 1-0-2 is equivalent to 1-2, so 1-0-2 = 1-2 > 1-1.
>
> That doesn't make much sense to me.
>
> I think the following line from the spec should be revised from:
>
> Then, starting from the end of the version, the trailing "null" values (0,
> "", "final", "ga") are trimmed.
>
> To:
>
> Then, starting from the end of the version string, all trailing "null"
> qualifier tokens ("", "final", "ga") are trimmed. All trailing numeric 0
> tokens that do not immediately follow a hyphen prefix (regardless of
> whether the hyphen is explicit or implicit) are likewise trimmed.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org