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

Cédric Champeau cedric.champeau at gmail.com
Thu Oct 26 10:21:49 UTC 2017

I'm in line with what Stephen said here, apart from the BETA scheme which gives wrong impression of low quality. I cannot speak for Gradle as an organization, but I can say we do have experience on what version numbers mean. For a library or a platform like the JDK, semantic versioning makes a lot of sense. So I would very much prefer:

One rationale for this is that we already fight with tracking version numbers for Java, because we need to support at runtime different versions (6 to 9, different vendors, ...) and we already see version strings like 9.0.1-ea.

It does NOT prevent the JDK from being branded as 18.3.LTS. So, marketing wise, you would have:

etc...

We just need a consistent versioning scheme, that is widely adopted and that tools can reason about. Unfortunately the 18.3 format doesn't allow us to infer anything about backwards compatibility.

2017-10-26 12:05 GMT+02:00 Stephen Colebourne <scolebourne at joda.org>:

On Twitter, the @VincentPrivat suggested "M" for milestone as a better term for the intermediate releases than "BETA". I agree. This would give:

9 (Set 2017) - now designated an LTS release 10-M1 (Mar 2018) 10 (Sept 2018) - an LTS release (example) 11-M1 (Mar 2019) 11-M2 (Sep 2019) 11-M3 (Mar 2020) 11 (Sep 2020) - an LTS release (example) Lets call this the MILESTONE version scheme in discussions. Again I emphasise that if this is not acceptable, the only rational choice is simple incrementing numbers as today, although in my view they fail to capture the lack of support / forced migration of non LTS releases, ie. whether something is LTS or not should be the primary driver of the version scheme IMO. Stephen On 25 October 2017 at 12:45, Stephen Colebourne <scolebourne at joda.org> wrote: > The "Support" axis is the wildcard in the whole discussion. While it > is true that in theory an implementor might provide LTS for release > other than those that Oracle provides LTS for, there is a huge open > question of whether they will, or whether it would be appropriate for > them to do so. This is a huge missing piece of the puzzle on > versioning, and can radically change the result of the discussion: > > For example, if Oracle and the community were to agree that LTS > releases are the new "real" releases, then the most appropriate > version scheme would be one that reflected that: > > 9 (Set 2017) - now designated an LTS release > 10-BETA-1 (Mar 2018) > 10 (Sept 2018) - an LTS release (example) > 11-BETA-1 (Mar 2019) > 11-BETA-2 (Sep 2019) > 11-BETA-3 (Mar 2020) > 11 (Sep 2020) - an LTS release (example) > etc

More information about the jdk-dev mailing list