Version-string schemes for the Java SE Platform and the JDK

[Remi Forax]

Yes, i was thinking exactly the same things reading the comments on this thread,
2018.3 is the distribution version, a position on the time axis while 10.0.0 is the internal version, a position on the compatibility axis (following JEP 223).

Not only SQL Server works that way, Windows also works that way and if we take a look to the past, jJva release where defined by there nickname (kestrel, tiger, mustang) [1] and not only by the 3-dots version not so long ago.

regards,
Rémi
[1] http://www.oracle.com/technetwork/java/javase/codenames-136090.html

----- Mail original -----
> De: "Dave Franken" <dwfranken at gmail.com>
> À: "Robert Scholte" <rfscholte at apache.org>
> Cc: jdk-dev at openjdk.java.net
> Envoyé: Dimanche 22 Octobre 2017 19:15:08
> Objet: Re: Version-string schemes for the Java SE Platform and the JDK

> How about using a separate version number for internal and public usage?
> 
> Internally, we can keep things semantic based on a more logical numbering
> starting with the current version, so just 9, 10 etc based on whatever is
> in the release.
> 
> Publically we can use whatever we want, such as yyyy.mm. I think it's
> important to show the difference between LTS and non LTS, so I would just
> use yyyy for the LTS versions and yyyy.update for intermediate non LTS
> versions.
> 
> SQL Server does this where SQL Server 2012 is 13.0 internally or something
> like that. And then you get R2 for an updated version.
> 
> Windows also always had a different internal and public version number.
> 
> Kind regards,
> 
> Dave Franken
> 
> 
> Op 22 okt. 2017 15:50 schreef "Robert Scholte" <rfscholte at apache.org>:
> 
> - Are there additional pros and cons to the alternatives listed above?
> 
> The usage of yy cons is that in case we want another version scheme in the
> future (e.g. back to SemVer-like scheme) we will be block once we reach
> version 17. We should not assume that this will be the final switch of the
> versioning scheme. JEP223 only being applied for Java 9  is a good example.
> Assuming the year will be part of the scheme, I would advice to use yyyy as
> the *official* version. That should give us enough room to do version
> comparison by recognizing the first segment as a year instead of a major
> version. (18.x also looks like a semver, which should be avoided)
> 
> Another con is that it is quite hard to recognize the LTS. I would prefer
> to have X.<LATEST> to be the LTS. That would imply that you could continue
> with the MM in the scheme. Assuming the version will start with the year,
> it might look like this:
> 
>                               (D)
>    GA (March 2018)            2018.03
>    First update (April)       2018.03.1
>    Second update (July)       2018.03.4
>    GA (September 2018)        2018.09
>    First update (October)     2018.09.1
>    Second update (January)    2018.09.4
>    GA (March 2019)            2018.15      (LTS)
>    First update (April)       2018.15.1
>    Second update (July)       2018.15.4
>    GA (September 2019)        2019.09
>    First update (October)     2019.09.1
>    Second update (January)    2019.09.4
> 
> I'm also worried about the version as passed to different jdktools, like
> source/target/release. Its value is easy to link with a certain Java
> version and there are no gaps. Switching the a year-based version scheme
> would either lead to gaps or to an alias that doesn't match the Java
> Version (e.g. 10 for 18.3)
> 
> thanks,
> Robert