- 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.4I'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