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

Andrew Haley aph at redhat.com
Thu Oct 26 10:28:34 UTC 2017


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.

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.

> Again I emphasise that if this is not acceptable, the only rational
> choice is simple incrementing numbers as today, 

This is rather strong.  Mark's suggestions are not irrational; on the
contrary, the choices are supported with reasoned argument.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


More information about the jdk-dev mailing list