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

[Alex Buckley]

Chen already gave some helpful comments, to which I will add:

On 11/3/2024 12:55 AM, Karsten Silz wrote:
> First, Alex Buckley clarified that not ALL tail releases must survive 
> the next tip release. In OpenJDK, three out of four don't. But must at 
> least ONE tail release outlast the next tip release every X years to 
> qualify the library for "tip & tail"? After all, the JEP "does not 
> specify when or why tail trains are created, nor when or why they are 
> discontinued."

In asking about "must", I think you're viewing JEP 14 as a specification 
that can be tested, leading to conformance badges being given, etc -- 
but it's not. JEP 14 outlines a philosophy -- "Give users what they want 
and don't give users what they don't want." -- and implements it with 
only a small tweak to the traditional multi-train release model: 
"Backport as little as possible."

If there's only one tail, and it's permanently abandoned in order to 
concentrate all effort on tip releases going forward, then the library 
isn't following a multi-train release model anymore, let alone T&T.

In order to claim you're doing T&T, you need to provide a tail that 
meets the needs of stability-focused users over an extended period. Some 
libraries might be able to fork and maintain a long-running tail (that 
outlives subsequent tips) every two years like clockwork. Other 
libraries might only be able maintain such a tail for a single notable 
historical release, and without being able to commit to when the tail 
releases will occur. In some domains, it might be OK if a library has 
feature-driven tip releases that appear every few years, plus a single 
tail train that makes releases infrequently (such that, for some time 
after a tip release, it's not clear if the tail is going to outlive the 
tip). This lack of timeliness might not be ideal for tail users, but it 
might be the reality for a library with limited maintenance resources.

(We're reaching the margins of multi-train development now. If even the 
low-cost T&T model can't keep a tail train maintained as tip releases 
come and go, then the library may as well give up on trains and declare 
itself one-size-fits-all. The users focused on stability will be 
disappointed, but no release model can conjure resources from thin air.)

> Second, can a library publish a bug fix release on the tip train? Or is 
> that automatically a tail release?

A tip release can absolutely have bug fixes only, with zero new 
features/enhancements. If a library has a rapid time-boxed release 
model, making tip releases every two months (say), then bugfix tip 
releases might occur more often than not. Given this frenetic tip 
energy, tail releases which *guarantee* zero new features/enhancements 
are even more relevant for users focused on stability -- who might even 
be satisfied with tail releases at a more stately pace, say, annually.

Alex