Verona spec: $PRE comparison

[Jörn Huxhorn]

On 21. August 2015 at 15:13:51, Magnus Ihse Bursie (magnus.ihse.bursie at oracle.com) wrote:
> On 2015-08-21 07:10, Iris Clark wrote:
> > Hi.
> >
> > We need to declare precedence when comparing numeric and non-numeric $PRE identifiers.  
> The present mixed numerical/lexicographical comparison is non-transitive and will  
> produce unexpected results. Consider the following three values of $PRE: "4", "2A",  
> and "12" which produces the cycle: 4 > 2A > 12 > 4.
> >
> > To address this problem while still aligning with semver.org, we should follow their  
> lead and declare a comparison precedence. The following sentence will be added to the  
> end of the $PRE comparison paragraph:
> >
> >> Numeric identifiers have lower precedence than non-numeric identifiers.
> > In the previous example we now have the following: 2A > 12 > 4.
>  
> But that's still weird, isn't it?
>  
> Sorting "2", "3" and "2-beta" anything else than "2", "2-beta" and "3"
> seems very surprising to me. And even if the intention is to allow
> numerical comparison with numbers (so 1, 2, and 10 is sorted in that
> order), this will nevertheless break down if a non-numerical character
> is introduced, e.g. "beta-1", "beta-2" and "beta-10" will not be sorted
> numerical anyway.
>  
> I strongly suggest that the PRE field is *purely* sorted on a
> lexicographical order. I believe that is the only way to achieve a sound
> sorting order.
>  
> /Magnus


The semver people have a good point with their pre being split into separate identifiers by dots.

beta1 < beta10 < beta2 but beta.1 < beta.2 < beta.10

I’d suggest to implement it that way since
- it makes sense while no one is forced to use it. beta1 would still behave like you suggest while beta.1 (currently not allowed by the spec because of the dot) would behave “properly”.
- being somewhat similar to semver but not really semver is worse than not being like semver at all because it can be confusing and surprising
- java.version won’t get parsed 1E9 times per app so this isn’t really about performance either, right?
- implementing semver and its comparison logic is actually very simple. See https://github.com/huxi/sulky/blob/master/sulky-version/src/main/java/de/huxhorn/sulky/version/SemanticVersion.java
- this new java version will likely stay around for a while. Wouldn’t it be a bit sad if we thought that having the above behavior would be neat two years down the road?


Cheers,
Jörn.