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