Accelerating the JDK LTS release cadence

[forax at univ-mlv.fr]

----- Original Message -----
> From: "mark reinhold" <mark.reinhold at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "discuss" <discuss at openjdk.java.net>
> Sent: Mardi 14 Septembre 2021 19:58:54
> Subject: Re: Accelerating the JDK LTS release cadence

Sorry for the late answer,

> 2021/9/14 8:12:11 -0700, Remi Forax <forax at univ-mlv.fr>:
>> As a user, i applaud the idea of having more choices but i've some
>> concerns:
>> 
>> - as a maintainer of some libraries, it will make my life more
>> complex, because the ecosystem will not evolve in lockstep as it was
>> before, i fear a scenario like Android were numerous LTS are used at
>> the same time by different people making the choice when to upgrade
>> quite complex.
> 
> There is already a vast range of releases in use today -- including
> releases earlier than JDK 8.  The ecosystem has never evolved in
> lockstep.
> 
> I agree that it’s likely that there will be more LTS releases in active
> use than there are today.  Thanks to changes we started making years
> ago, however, in particular the encapsulation of JDK internals [1], I
> don’t think that will be a big problem.  Many library maintainers have
> found that once they move past JDK 8 it’s pretty easy to keep up with
> every six-month feature release, LTS or not.

yes,

> 
> As a library maintainer you can choose a baseline JDK release depending
> upon the new features you want to use, and then stick to building with
> that baseline for years if you like.  During that time, just make sure
> that it continues to run on the latest LTS release while still building
> with the baseline.  Even better: Spread your effort out over time, and
> give your users the option of using non-LTS releases, by tracking every
> six-month feature release instead.

As a library maintainer, there are two factors,
either i will upgrade when one of the dependency upgrade (by example Guava support Java 8+) or
i will upgrade if a new feature allows me to have a better API (like lambdas).

The former reason is why the ecosystem mostly evolve in lockstep, once several popular libraries target a new version of Java, most of the libraries move to that version.

> 
>> - as an OpenJDK member, we now that LTS has an impact of the
>> development of the JDK, stewards are less available before a LTS,
>> there are more migration documentations to write etc, so for me this
>> proposed change will slow down the OpenJDK development not accelerate
>> it.
> 
> My perspective from inside Oracle is that most of us working on JDK 17
> itself have spent hardly any more time on it at all as compared to the
> preceding non-LTS releases.  We’ve been writing release notes, updating
> migration guides and other documentation, and so forth for every single
> six-month feature release.  Do you have evidence to suggest that we’ve
> been less available?

I will not snitch on anyone :) 

> 
>> - some people will start to think in term of feature releases again
>> when big features like Loom or Valhalla will land. I'm ok with a LTS
>> without a big feature or a LTS with more than one big features but i
>> fear that not everybody will agree on that. A 3 years is a long time,
>> that shield us from that kind of discussions.
> 
> People who want big features to align with LTS releases are, in effect,
> arguing for a return to the old unpredictable feature-driven release
> model.  We abandoned that model in 2017.  Do you want to go back?
> 
> There will always be discussions about which features are, or are not,
> or should be, or shouldn’t be, in a particular release.  Let’s not be
> unduly distracted by them.

I agree.

I've discussed with quite a lot of people during this week, most of them prefer a 2 year schedule for a LTS.
2 years is good for application developers, 3 years is better for library maintainers. There is at least 10x more application developers, so i will shut my big mouth.

> 
> - Mark

Rémi

> 
> 
> [1] https://openjdk.java.net/jeps/403