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

[Stephen Colebourne]

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.

Again I emphasise that if this is not acceptable, the only rational
choice is simple incrementing numbers as today, although in my view
they fail to capture the lack of support / forced migration of non LTS
releases, ie. whether something is LTS or not should be the primary
driver of the version scheme IMO.

Stephen

On 25 October 2017 at 12:45, Stephen Colebourne <scolebourne at joda.org> wrote:
> The "Support" axis is the wildcard in the whole discussion. While it
> is true that in theory an implementor might provide LTS for release
> other than those that Oracle provides LTS for, there is a huge open
> question of whether they will, or whether it would be appropriate for
> them to do so. This is a huge missing piece of the puzzle on
> versioning, and can radically change the result of the discussion:
>
> For example, if Oracle and the community were to agree that LTS
> releases are the new "real" releases, then the most appropriate
> version scheme would be one that reflected that:
>
> 9        (Set 2017) - now designated an LTS release
> 10-BETA-1 (Mar 2018)
> 10        (Sept 2018) - an LTS release (example)
> 11-BETA-1 (Mar 2019)
> 11-BETA-2 (Sep 2019)
> 11-BETA-3 (Mar 2020)
> 11        (Sep 2020) - an LTS release (example)
> etc