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

Mario Torre neugens.limasoftware at gmail.com
Fri Oct 20 12:57:03 UTC 2017

2017-10-19 17:08 GMT+02:00 <mark.reinhold at oracle.com>:

Hi Mark,

Thanks for bringing this to a broader discussion, it is very appreciated that you are involving the community.

If you've read this far, my question to you now is not the question that you might expect. Please don't say which version-number scheme you prefer for Java SE and the JDK. Instead, please only communicate any additional information that's relevant to the choice of such a scheme. In particular:

- Are there additional pros and cons to the alternatives listed above? - Are there additional alternatives worth considering, and if so what are their pros and cons? - Are there specific experiences with other projects or products that can inform this choice?

It is very difficult to participate without saying which version scheme one prefer...

I think the important information of any release are:

  1. Is an LTS?
  2. Is a Security update?
  3. Does it have the latest Security patches?

I believe that those questions, especially the latter twos, are already addressed by the current scheme, while there's no information if we move solely on a time based visioning. For sequential updates we may be able to live with "always use the latest", but when they overlap wth LTS would make this understanding more complex.

We can perhaps keep both worlds by adding the release date to the incremental version scheme if you really want, having an API that exposes it, like "10.0.1 (2018.05)", which clearly reads as "first security release of 10, released in May 2018". If the release date is all the important, that is.

Eventually, especially in production systems, the LTS is going to be the version used the most, so I would humbly suggest to figure out a different version scheme that fits for the LTS first and then walk all the way down to the "regular" releases, if anything.

Cheers, Mario

-- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards: http://endsoftpatents.org/

More information about the jdk-dev mailing list