<div dir="ltr">Hi Alex,<div><br></div><div>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.</div><div>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. </div><div>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,...</div><div><br></div><div>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:</div><div>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". </div><div>The definition of such an "exception" is a bit vague, probably on purpose since it depends on many criteria (some library-specific).</div><div>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. </div><div>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.</div><div><br></div><div>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:</div><div>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)</div><div>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).</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>- Johan</div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 3, 2024 at 11:10 PM Alex Buckley <<a href="mailto:alex.buckley@oracle.com">alex.buckley@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Everyone on jdk-dev is familiar with the six-month cadence of JDK<br>
feature releases (21, 22, 23 ...) and the three-month cadence of JDK<br>
update releases (21.0.1, 21.0.2, 21.0.3 ...).<br>
<br>
This two-pronged release model delivers major innovation as soon as it's<br>
ready, such as virtual threads in JDK 21 and the Foreign Function &<br>
Memory API in JDK 22, while providing a conservative stream of updates<br>
for users who prefer to stay on older releases.<br>
<br>
In recent years we've taken to calling this the "tip & tail" release<br>
model. The tip (the latest feature release) appeals to users building<br>
new systems, as well as users who want the largest possible set of bug<br>
fixes and performance improvements. The tails (various update releases)<br>
appeal to users maintaining long-lived systems, by backporting only<br>
select bug fixes and improvements and smartly avoiding the code churn<br>
associated with backporting new features. Minimizing backports from tip<br>
to tail means that more tails can be maintained, for longer.<br>
<br>
If you're interested in tip & tail, please see the informational JEP<br>
that we've just published:<br>
<br>
   <a href="https://openjdk.org/jeps/14" rel="noreferrer" target="_blank">https://openjdk.org/jeps/14</a><br>
<br>
If you'd prefer to watch a video, the JVM Language Summit keynote on<br>
"Java in 2024" is all about tip & tail:<br>
<br>
   <a href="https://www.youtube.com/watch?v=NV4v7KXKQ-c" rel="noreferrer" target="_blank">https://www.youtube.com/watch?v=NV4v7KXKQ-c</a><br>
<br>
We hope all library maintainers in the Java ecosystem will consider<br>
adopting the tip & tail release model. Users who want the latest and<br>
greatest would take the tip releases of libraries, which use tip<br>
releases of dependencies, all the way down to the tip JDK. Users who<br>
prefer stability would take the tail releases of libraries, which use<br>
tail releases of dependencies, all the way down to a tail JDK. It's a<br>
better experience for application developers, and surprisingly easy for<br>
library developers ("backport as little as possible"). The entire Java<br>
ecosystem stands to gain.<br>
<br>
Alex<br>
</blockquote></div>