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

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