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