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

[Robert Scholte]

- 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