JEP 223: New Version-String Scheme

[Jörn Huxhorn]

Hi Iris,

I just gave Semantic Versioning 2.0.0 (SV2) a proper read (I was on the run when I wrote my previous mail) and they have the notion of "a series of dot separated identifiers” for both pre-release version and metadata. Those dot separated identifiers are compared individually and identifiers consisting of only digits are compared numerically.

This means that alpha.1 < alpha.2 < alpha.10 while alpha1 < alpha10 < alpha2, a useful feature.

JEP 223 does not currently allow a pre-release version like that since it doesn’t even allow a ‘.’.

If this is changed then the proposed API should be changed from
public Optional<String> pre();
to
public List<String> pre();
That way the pre() List could be used efficiently in the implementation of the compareTo method.

If this is not changed then the pre-released String should always be compared lexically since we can’t really ensure a more reasonable sorting anyway.


JEP 223 $BUILD and $OPT are both part of the SV2 "metadata identifiers" and JEP 223 +BUILD-OPT would still be valid metadata according to SV2. JEP 223 is simply stricter than SV2 in that it requires a numerical build number as the first identifier of the metadata.

It would be reasonable to also change
public Optional<String> optional();
to
public List<String> metadata();
and simply rule that the first element, if any, must be the numerical build number - just for the sake of consistency.

But since we don’t actually need $BUILD and $OPT for sorting, this wouldn’t really be necessary.

What do you think?

Cheers,
Jörn.

On 15. Juli 2015 at 20:40:41, Jörn Huxhorn (jhuxhorn at googlemail.com) wrote:
> Hi Iris,
>  
> Thanks for your answers. Very much appreciated.
>  
>  
> On 15. Juli 2015 at 20:18:39, Iris Clark (iris.clark at oracle.com) wrote:
> > JEP 223 is currently targeted for JDK 9 (see the "Status" and "Release"
> > fields).
>  
> I saw that. I just wasn’t 100% sure about the values the Status field can have and what exactly  
> “Targeted" means. Thanks for clearing that up.
>  
>  
> > > The "Pre-release identifiers are compared numerically when they consist only
> > > of digits, and lexicographically otherwise.” part is a bit concerning and
> > > doesn’t really adhere to the principle of least surprise.
> >
> > > I currently handle it this way in Comparable:
> > > http://pastebin.com/7xaizUKm …but it makes me feel kind of dirty.
> >
> > > Wouldn’t it make more sense to just rule that pre should be compared
> > > lexicographically? I think
> > > https://bugs.openjdk.java.net/browse/JDK-8061493?focusedCommentId=13602386&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13602386  
> > > has a very valid point.
> >
> > Hmmm... I'm going to have to think about this. The comparison was supposed to
> > attempt to align us with semver.org handling of pre-release identifiers.
> > There have also been some considered adjustments to that area of the spec
> > since it was originally written to handle specific concerns. I'm going to
> > need to dig out my notes.
>  
> With the current compareTo implementation according to the spec, sorting of versions  
> is behaving quite erratic:
>  
> Collections.sort([9.0.0-4, 9.0.0-2A, 9.0.0-12]) => [9.0.0-12, 9.0.0-2A, 9.0.0-4]  
> Collections.sort([9.0.0-4, 9.0.0-12, 9.0.0-2A]) => [9.0.0-4, 9.0.0-12, 9.0.0-2A]  
> Collections.sort([9.0.0-12, 9.0.0-2A, 9.0.0-4]) => [9.0.0-12, 9.0.0-2A, 9.0.0-4]  
> Collections.sort([9.0.0-12, 9.0.0-4, 9.0.0-2A]) => [9.0.0-2A, 9.0.0-4, 9.0.0-12]  
>  
> This just can’t be correct.
>  
> I just checked http://semver.org/
>  
> Paragraph 11 contains the following definition which would fix this problem:
> "Numeric identifiers always have lower precedence than non-numeric identifiers."  
>  
> I think this should also be added to JEP 223 accordingly. I’ll definitely go ahead and  
> implement it that way instead.
>  
> Cheers,
> Jörn.
>