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

[Andrew Haley]

On 25/10/17 12:45, Stephen Colebourne wrote:

> I've outlined the BETA scheme above. To me it most clearly
> represents what the wider community would expect, as I think if you
> asked them, only LTS releases with support would count as "real"
> releases worthy of changing the first digit, and all other
> "releases" are simply betas working towards the LTS. Note that this
> implies that no piece of functionality can be deprecated in BETA1
> and removed in BETA2, which would be a sensible approach anyway.
> 
> The main con of the BETA scheme is that it encodes a specific LTS
> model into the version scheme. And I suspect there might be some
> pushback on the principle of downgrading 6 monthly release relative
> to the LTS ones. In my view this is actually just a statement of
> fact - as without support you are forced to upgrade making them
> clearly a lower grade of release.
> 
> Now, if RedHat 

It's "Red Hat".

> or someone else were to publicly say that they will support every 6
> monthly release for a 5 year period, then the BETA scheme doesn't
> work. But IMO, the community would be better served by a widely
> agreed LTS release every 2 to 3 years, with BETA releases in between
> for advanced users.

That may well be how it turns out, but we should not attempt to
enforce that in the numbering scheme.  For example, some organizations
might well choose to take a six-month update which doesn't break
anything but has some performance improvements and merge that into
their LTS release.  Thinking of the six-month releases as Betas
doesn't help.

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