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

[Cédric Champeau]

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:

- 10.0.0 // first 10 release
- 10.1.0 // adds new APIs, backwards compatible, NO class version upgrade
- 11.0.0 // adds new APIs, backwards compatible maybe, BUT increases class
version number because of new feature X

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:

- 18.3.LTS -> 10.0.0 (internal version number, used by tools and referring
to the actual platform version)
- 18.9 -> 11.0.0

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
>