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

Mikael Vidstedt mikael.vidstedt at oracle.com
Fri Oct 27 02:55:36 UTC 2017

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

More information about the jdk-dev mailing list