New informational JEP: 14: The Tip & Tail Model of Library Development

[Alex Buckley]

On 11/12/2024 3:34 AM, Karsten Silz wrote:
> So, users with JDK 17 would not have gotten any non- 
> JDK-21 new features from 3.2, like support for CRaC or the new HTTP 
> client, because they could only use the 3.1 tail train.

The library maintainers are free to make a 3.2 tip release without 
virtual threads, baselined on JDK 17, and offers cheap 3.2.x tail 
releases for many years.

But once the maintainers make a tip release with virtual threads, 
baselined on JDK 21, they're indicating that they've moved on from JDK 
17, just as they moved on from JDK 11, 8, 7, 6, etc. Users who wish to 
stay on JDK 17 after that are free to do so -- they can look forward to 
17.0.14, 17.0.15, 17.0.16, and 17.0.17 in 2025 -- but they can no longer 
expect new features from the library. That's OK: they don't care about 
new features because their applications are already deployed and don't 
need a new HTTP client. Users who are actively developing applications 
should be using the tip JDK (or the most recent LTS, 21) and will have 
no problem with the library's tip release being baselined on 21.

There will always be users of an older JDK who take the position that: 
If library maintainers _can_ make new library features run on the older 
JDK, then the maintainers _should_ make the features run on the older 
JDK. For example, the new HTTP client was introduced in JDK 11 in 2018; 
I'm sure there are some people who run an old Spring release on JDK 
11.0.x and would like support for the new HTTP client to be backported 
from Spring 3.y to the old Spring release. You can imagine the 
impassioned requests from these people as they explain why maintainers 
"should" do the backport. The T&T model says: those people are few, 
outnumbered by a silent majority that wants bug fixes and security 
patches and nothing else for their older libraries on JDK 11, so the 
thing that maintainers "should" do is say no and move on with their day.

Alex