Fwd: Impact of six month releases (original) (raw)

Stephen Colebourne scolebourne at joda.org
Thu Nov 2 23:31:43 UTC 2017

(originally sent to the wrong list)

Like many others my first reaction on hearing of six monthly releases was very positive. Great to see things move forward faster. However, as time has progressed and more detail has come out I find myself struggling to see how it is actually useful in practice.

This is the proposed timeline (as I understand it):

Note that there is no overlap between the last v10 update (security) release 10.0.2 and the first v11 release. In order to be protected in security terms developers are required to upgrade to 11.0.0 immediately on release.

I believe that this cannot work in practice.

Every single major (feature) release of Java I can remember has caused a problem in at least one of the tools in the stack of the application I was working on. To upgrade to a new Java major/feature version I'd currently need all of these to be ready:

If just one of these isn't ready then I can't upgrade to the new version of Java.

Now, historically, the solution to upgrading has been to wait. Over time, the open source community would - often in their unpaid spare time - bring the stack back to be working again. Traditionally, it has taken many months for the point where the whole stack is viable again.

But to state the obvious - this simply does not work anymore.

If it takes 3 months for the stack to be viable again (hugely optimistic) the version has just 3 months of life before the whole cycle has to start again. My experience would actually say that 6 months (and 2 updates) is generally the point at which the stack is fully stable and it would be OK to put a system into production. But, the six month point is where you get no more security updates. The logical conclusion is that this is a trap, and you should therefore not attempt to join the eternal upgrade train.

As it stands, the only advice any consultant or experienced developer could give would be to stick with Java 8 or a future LTS (which is in theory v12, but with time-boxing it seems unwise to rely on that). The intermediate releases between LTS versions are fundamentally unsuited for use in production systems. In fact one might sensibly call them "milestones"...

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.

Stephen

More information about the jdk-dev mailing list