Fwd: Impact of six month releases

[Stephen Colebourne]

(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):

- 10.0.0 - Feature release March 2018
- 10.0.1 - Update release April 2018
- 10.0.2 - Update release July 2018
- 11.0.0 - Feature release September 2018
- 11.0.1 - Update release October 2018
- 11.0.2 - Update release January 2019
- 12.0.0 - Feature release March 2019

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:

- Eclipse
- IntelliJ
- Travis CI
- Shippable
- Amazon AWS
- Maven
- Maven plugins (compile, jar, source, javadoc, site, etc)
- Checkstyle, & associated IDE plugins and maven plugin
- JaCoCo, & associated IDE plugins and maven plugin
- PMD, & associated maven plugin
- SpotBugs, & associated maven plugin
- OSGi bundle metadata tool
- Bytecode tools (Byte buddy / ASM etc)
- Over 100 jar file dependencies
- Probably something else I've forgotten

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