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

Dave Franken dwfranken at gmail.com
Sun Oct 22 17:15:08 UTC 2017

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

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