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

[Dave Franken]

Now that I've read a lot of arguments in this discussion, I'm beginning to have some doubts about the whole "time based just include what's ready" release cycle, especially with regards to LTS versions and backwards compatibility.

If we don't do any cherry picking about the types of features that end up in a release, we could have the version number bumping all over the place.
We could go from 9 to 10 to 11 in 2018 alone (10 being the March version and 11 being the September LTS version).

Backwards compatibility has always been Java's strong suit, but it came at a cost of slow language improvements.
With the proposed release cycle and version numbers, I feel the pendulum swings too far to the other side.

Can we have the best of both worlds?

I think that there should be some more discussion about not just the version numbers, but the reason we have to argue about them in the first place, the underlying issue of time based releases.

My proposal is that there should be some restraint in adding backwards incompatible features in non-LTS releases, for instance local type inference (JEP 286) and value types (project Valhalla).
A non-LTS version may incorporate all finished features that don't result in bumping $MAJOR.
This means that developers don't have to worry about using non-LTS versions, they also don't feel like Betas, just updates to the version you might already be using.
They only have internal performance improvements, security fixes etc that don't break your code.

Issues that break backwards compatibility should still be bundled in LTS versions, we should just strive to not have to wait many years for them.

Applying Stephen Colebourne's example to my proposal would result in:

9        (Sept 2017) - now designated an LTS release(?)
9.1    (Mar 2018)
10     (Sept 2018) - an LTS release (example, including JEP 286)
10.1 (Mar 2019)
10.2 (Sep 2019)
10.3 (Mar 2020)
11    (Sep 2020) - an LTS release (example, including project Valhalla)

We can still have more frequent releases while being careful about backwards compatibility.

Kind regards,
Dave Franken

-----Original Message-----
From: jdk-dev [mailto:jdk-dev-bounces at openjdk.java.net] On Behalf Of Mario Torre
Sent: woensdag 25 oktober 2017 22:29
To: Stephen Colebourne <scolebourne at joda.org>
Cc: jdk-dev at openjdk.java.net
Subject: Re: Version-string schemes for the Java SE Platform and the JDK

2017-10-25 13:45 GMT+02:00 Stephen Colebourne <scolebourne at joda.org>:
> 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:

I resisted the urge to reply on other posts as per Mark's original request, but I think it's very important that we keep in mind that the short lived released in between the LTS are not beta, they are full high quality, stable and production ready releases.

While I also think that LTS will be the one most used in the industry, it's only because they live longer, they don't necessarily have a special merit over any other release.

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/