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

[Dave Franken]

It seems paradoxical to want to have both a rapidly evolving language and LTS-versions.

Personally, I would be okay with having "just releases" containing everything that is releasable, whether it has incompatible features or not, as long as the version number reflects it.
So basically JEP 223. No betas, no milestones, just $MAJOR.$MINOR.$PATCH/$SECURITY.
Every release is stable and has new (possibly breaking) features, improvements, bug fixes, etc, so you can decide to upgrade based purely on the version number alone, telling you the most important information.

We then have to ask ourselves: how many versions are we going to support with security updates?
Say we quickly (within 1 year) arrive at version 11 because version 10 (18.3) has local type inference and 11 (18.9) has value types and at that point we have to do a security update.

Which versions are we going to update? If we keep updating too many old versions, the sense of urgency to move on is lessened.
But if we decide to only support the latest two versions (10 and 11), there is no way to tell how long your version will be supported.

If you are still stuck on 10, it could be 2 years until 12 comes out (ending support for 10), or it could be 6 months, it just depends on what kinds of features are ready at that time.
I'm all for a rapidly evolving language, much of the enterprise is getting ready for it with the use of containerized environments where upgrading Java is just a matter of changing a number somewhere.

I just want to make sure we have ironed out all of the wrinkles before committing ourselves fully.
The version number debate brings to light very important questions that are not strictly related to the version number, but are worth discussing in their own right.

Dave Franken

-----Original Message-----
From: jdk-dev [mailto:jdk-dev-bounces at openjdk.java.net] On Behalf Of Mikael Vidstedt
Sent: vrijdag 27 oktober 2017 4:56
To: Andrew Haley <aph at redhat.com>
Cc: jdk-dev at openjdk.java.net
Subject: Re: Version-string schemes for the Java SE Platform and the JDK


> On Oct 26, 2017, at 3:28 AM, Andrew Haley <aph at redhat.com> wrote:
> 
> On 26/10/17 11:05, Stephen Colebourne wrote:
>> 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.
> 
> Let's not.  Six-monthly releases are releases, not milestones.
> 
> IMO:
> 
> This whole discussion has been mistracked by the notion that we're 
> going to continue with Java development as we have in the past, with 
> true big feature releases every few years.  That is wrong, and it has 
> to end.  Java is hurting because we are not getting the benefit of the 
> release early, release often loop.  Done right, this allows 
> development to proceed more quickly and gets faster feedback from 
> users.  The world of language development outside Java is moving much 
> faster, and we run the risk of becoming a dinosaur if we're too slow.

Well said, thanks for summing up my thoughts for me :)

> I know this has risks.  It pushes the edges of our comfort zones.  But 
> it's also exciting and could be terrific if done well.

The new release model comes with a whole bunch of new challenges and risks for sure, but it’s not like the current model is problem free (understatement of the day?). I agree that this is a very exciting opportunity and I’m looking forward to working through issues as they arise.

Cheers,
Mikael