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