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

Alex Buckley alex.buckley at oracle.com
Thu Oct 31 21:03:50 UTC 2024


On 10/31/2024 4:44 AM, Karsten Silz wrote:
> To me, stability depends on the answer to this question: When and how do 
> I have to upgrade when I want to stay up-to-date with tail trains only? 
> I think the JEP does not mandate when tail trains appear or how long 
> they live, which does not give me the stability I want.

There are tens of thousands of libraries in the Java ecosystem. It is 
plainly impossible to mandate anything about the scheduling or longevity 
of tail trains. All the JEP does is explain why tail trains should exist 
in the first place.

> The tip & tail example from section “Backport as little as possible”, 
> for instance, has tail trains at seemingly random intervals. Some “tip 
> generations”, like 1 and 4, don’t get tail trails at all. And it’s not 
> clear whether the tail trains have the same duration. This example does 
> not give me stability.

The example is saying that the project maintainers wanted to support 
users of 2.x and 3.x on a long term basis. It doesn't matter why the 
maintainers wanted to do that, or why they didn't feel the need to 
support 1.x users and 4.x users. What matters is that users of 2.x and 
3.x get tail releases (2.1.* and 3.1.*) for a period that is likely to 
be much longer than if a traditional multi-train approach was used. It's 
likely to be much longer because maintaining tails is cheap:

1. As little as possible is backported to the tails from 4.x and 5.x.

2. The tails only need to run on the JDK where they were originally 
baselined -- maintainers don't need to test, say, 2.1.* on JDK 21 or 25.

Maintainers choose how often to make 2.1.* and 3.1.* tail releases. It 
doesn't matter to the T&T philosophy whether maintainers choose 
quarterly, monthly, annually, or any other period.

> The first real-life example in the JEP does: In Java, I either upgrade 
> every six months or every 2-5+ years, depending on my JDK distribution’s 
> LTS  duration. That’s perfect stability to me.

If you're running a JDK LTS version, you should be upgrading every three 
months. For example, so far in 2024, a JDK 17 user should have upgraded 
to 17.0.10, 17.0.11, 17.0.12, and 17.0.13.

T&T is not about upgrading less. It's about upgrading to get the things 
you want, and not the things you don't want.

Alex


More information about the jdk-dev mailing list