Impact of six month releases

[Andrew Haley]

On 02/11/17 23:06, Stephen Colebourne wrote:
> Given the above, I find this proposal from Mark, deeply concerning:
> 
> "Features may be added in a feature release; they may also be removed,
> if advance notice was given at least one feature release ahead of
> time."
> 
> The statement above indicates that code can be deprecated and removed
> in just two releases. But there are 5 intermediate releases between
> LTS ones on the current schedule (from 12 to 18). This means that
> developers moving from LTS v12 to LTS v18 will probably see code fail
> to compile without ever seeing a deprecation.
> 
> 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.

We who work on Java will be no more reckless than we have been in the
past.  We know that people need to trust Java, and don't want to lose
that trust in us.  But if we do something that turns out to have been
a mistake, and everyone agrees that it was a mistake, we must not be
constrained simply because the rules forbid us from fixing it.

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