Version-string schemes for the Java SE Platform and the JDK (original) (raw)

Remi Forax forax at univ-mlv.fr
Sun Oct 22 18:24:37 UTC 2017

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. 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

More information about the jdk-dev mailing list