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

[Johan Vos]

Hi Alex,

Thank you very much for writing the JEP and starting this mail thread. Over
the past months, my appreciation for the Tip & Tail model has grown. My
initial worry was that it would require more work for the library
maintainers, but I gradually started to see the benefits and today I'm a
big fan.
One of the main benefits, imo, is the clarity and predictability. We
already have sort of Tip and Tail releases in JavaFX and other libraries I
(co-)maintain, but it was never called like that, and consumers of the
libraries were not sure what to expect.
The JEP makes a number of things crystal clear, and also provides enough
freedom to individual library owners/maintainers to make the most
project-appropriate decisions, e.g. number of supported tails, version bump
algorithms,...

I believe this JEP will solve lots of discussions and provide much
clarity, and the advantages are well described in the JEP. However, I also
think it will highlight one of the root problems library maintainers are
struggling with, which I want to touch on in this thread:
The main "question" I have is about the "backport as little as possible" --
which I believe is a principle most library maintainers agree with. In the
section "Do not backport new features and performance improvements", there
is a paragraph about "exceptions".
The definition of such an "exception" is a bit vague, probably on purpose
since it depends on many criteria (some library-specific).
However, in absence of a clear definition, I expect lots of discussions
about this. Consumers of a library will try to convince maintainers to fix
a "simple but critical" bug -- which can be a real simple 3 line patch that
is completely isolated and is almost certainly not changing any behavior at
all.
The latter is however never guaranteed. I observed that Tail users often
"rely" on imperfections in a codebase -- e.g. they know that X and Y are
being done in parallel, and they know that X is faster than Y, even if it
is not in the spec, so their code is implicitly built on this. Clearly,
this example is bad practice, but more subtle cases are very common in
JavaFX projects (where the specs do not always clearly determine exactly
what visual outcome can be expected). Hence, even the smallest change can
result in major issues in a real-world application in production systems on
a Tail train.

>From the JEP, I assume that the call to decide if something is "an
exception" and should get backported is at the discretion of the library
maintainer. But as a library maintainer, you're in a very difficult
position:
1. You say "NO" to the request of backporting a very simple fix. The
requester (and many users) is disappointed (for good reasons) and doesn't
understand why you don't want to change something that trivial (given that
you're already backporting security fixes that are way more complex). The
pressure becomes higher if a maintainer reads on social media that he's
doing a bad job because "I created a PR and "they" don't want to merge it
even though it works!" (that behavior is a separate topic though)
2. You say "YES" and after some time, you get a major complaint from the
biggest user of the Tail train, because their application started to behave
very wrong and they lost lots of money because of this. Ugh. (not all
library maintainers have a legal department to deal with this).

Unless the criteria for exceptions are specified very clearly, there will
always be these difficult decisions for library maintainers. I completely
understand that it is not part of the JEP to define those criteria. Maybe
there can be library-specific guidelines though, e.g. P5 bugs should never
be backported, while P2 bugs can get backported only if they are reviewed
by N reviewers. But I assume it will be really hard to define those, and by
no means I want to suggest that these should be part of the JEP.

Overall, this is a great JEP that can guide the Java ecosystem into a good
direction, and when adopted by most relevant libraries, it will create
clarity, and reduce the need for ugly code hacks that check the version of
the JDK or libraries at runtime. Being realistic, it will probably reduce
the technical pressure on library maintainers, but not (completely) the
social/legal pressure.

- Johan


On Thu, Oct 3, 2024 at 11:10 PM Alex Buckley <alex.buckley at oracle.com>
wrote:

> Everyone on jdk-dev is familiar with the six-month cadence of JDK
> feature releases (21, 22, 23 ...) and the three-month cadence of JDK
> update releases (21.0.1, 21.0.2, 21.0.3 ...).
>
> This two-pronged release model delivers major innovation as soon as it's
> ready, such as virtual threads in JDK 21 and the Foreign Function &
> Memory API in JDK 22, while providing a conservative stream of updates
> for users who prefer to stay on older releases.
>
> In recent years we've taken to calling this the "tip & tail" release
> model. The tip (the latest feature release) appeals to users building
> new systems, as well as users who want the largest possible set of bug
> fixes and performance improvements. The tails (various update releases)
> appeal to users maintaining long-lived systems, by backporting only
> select bug fixes and improvements and smartly avoiding the code churn
> associated with backporting new features. Minimizing backports from tip
> to tail means that more tails can be maintained, for longer.
>
> If you're interested in tip & tail, please see the informational JEP
> that we've just published:
>
>    https://openjdk.org/jeps/14
>
> If you'd prefer to watch a video, the JVM Language Summit keynote on
> "Java in 2024" is all about tip & tail:
>
>    https://www.youtube.com/watch?v=NV4v7KXKQ-c
>
> We hope all library maintainers in the Java ecosystem will consider
> adopting the tip & tail release model. Users who want the latest and
> greatest would take the tip releases of libraries, which use tip
> releases of dependencies, all the way down to the tip JDK. Users who
> prefer stability would take the tail releases of libraries, which use
> tail releases of dependencies, all the way down to a tail JDK. It's a
> better experience for application developers, and surprisingly easy for
> library developers ("backport as little as possible"). The entire Java
> ecosystem stands to gain.
>
> Alex
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20241107/4e93b0c8/attachment.htm>