Impact of six month releases

[Andrew Haley]

On 03/11/17 14:41, Stephen Colebourne wrote:
> On 3 November 2017 at 09:14, Andrew Haley <aph at redhat.com> wrote:
>>> I think this is throwing the baby (Java's long standing backwards
>>> compatibility) out with the bathwater (frequent releases), but I'm
>>> happy to hear other opinions.
>>
>> I don't believe that such worries are necessarily justified.
>>
>> We need to be able to roll back mistakes.  The Java tradition that
>> nothing ever gets removed, no matter how much mistaken, holds back
>> innovation.  It does this because of a justified fear that if we make
>> a mistake, we're stuck with it, so we have to be ultra-cautious.
> 
> I think its more than that. Java's success is built on the broader
> ecosystem. The JDK itself is an enabler for that. Open source projects
> have to be able to produce jar files that work on multiple releases of
> the JDK. Things that prevent that are a big issue.

What would prevent that?  A new feature that turns out to be a bad idea
will only be a problem if someone actually uses it.  Everybody else can
build jarfiles that are backwards compatible, and probably will.

> In practical terms I'd argue that:
> 
> 1) LTS releases define the removal cycle. Code added in a  non-LTS
> release (n) can be deprecated in the next non-LTS release (n+1) and
> removed in the release after that (n+2). This works because the code
> was never in an LTS release. However, code that *was* in the last LTS
> release cannot be removed until the release after the next LTS.

That might happen, but we must not bake such a restriction into our
processes.  LTS releases are not anything special: they are a freeze
of the state of OpenJDK at one time.

> eg. code present in 8 cannot be removed until 12 (as 11 is the first
> LTS where the deprecation is visible)
> eg. code added in 12 can be deprecated in 13 and removed in 14 as 12
> and 13 are non-LTS
> 
> 2) There should be more than 2 security updates for each release.
> Without an overlap period, developers are forced to upgrade to the
> next release immediately it is GA. This does not reflect real-world
> software development practice. If the non-LTS releases are to be used
> in production they will need a bare minimum of 4 security updates (one
> year) to create a time window overlap with the next release.

I don't think that should be baked in either.  Security updates are a
lot of work.  It's by no means guaranteed that people will have
sufficient engineering resources to do that.  We have the largest team
doing independent OpenJDK releases at Red Hat, and I don't think that
we'd want to commit to doing it.

> 3) The javac --release flag should work for at least the last three
> LTS releases. A time-window of 10 years would also be about right.
> (Its a *really* convenient feature, and if possible I'd prefer it to
> never lose support for older versions).

That seems reasonable, but again I don't want to see it baked in to the
rules.

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