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

Karsten Silz karsten.silz at gmail.com
Thu Oct 31 11:44:07 UTC 2024


Tip & tail is necessary for stability. But is it sufficient?

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. 

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 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. 

The second example, Spring Boot, is not as stable: I get monthly tail releases. That's great. And I could switch tail trains every six months but have to every twelve. That’s not great but good.

But I don’t know when a Spring Framework generation ends. And new generations typically raise the JDK baseline (6 won’t) and may force major dependency upgrades, which could be a lot of work for me.  That’s bad. For example, generations 3 and 4 lasted four years, 5 got five years, and 6 will only last three. The last Spring Boot tail release of a Spring generation typically lasts 18 months. But the extra six months may not be enough to make the jump.

Is my definition of stability too strict? Or do I have a minority definition of stability?


Karsten Silz


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20241031/b8ec76e7/attachment.htm>


More information about the jdk-dev mailing list