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 <[email protected]> > > 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 <[email protected]> > > > > 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: [email protected] For additional commands, e-mail: [email protected]
