
<html><head><meta http-equiv="content-type" content="text/html; charset=us-ascii"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><br></div></div></div><div><blockquote type="cite"><div>On 4 Nov 2024, at 18:52, Alex Buckley <alex.buckley@oracle.com> wrote:</div><br class="Apple-interchange-newline"><div><div>Chen already gave some helpful comments, to which I will add:<br><br>On 11/3/2024 12:55 AM, Karsten Silz wrote:<br><blockquote type="cite">First, Alex Buckley clarified that not ALL tail releases must survive the next tip release. In OpenJDK, three out of four don't. But must at least ONE tail release outlast the next tip release every X years to qualify the library for "tip & tail"? After all, the JEP "does not specify when or why tail trains are created, nor when or why they are discontinued."<br></blockquote><br>In asking about "must", I think you're viewing JEP 14 as a specification that can be tested, leading to conformance badges being given, etc -- but it's not. JEP 14 outlines a philosophy -- "Give users what they want and don't give users what they don't want." -- and implements it with only a small tweak to the traditional multi-train release model: "Backport as little as possible."<br></div></div></blockquote><div><br></div><div>Thank you very much for this clarification! I did indeed think this was a more formal spec, not more like a whitepaper. </div><div><br></div><div>What I'm still not sure about is how do you think you'll reach your goal? I didn't find a call to action in there, such as "All Java libraries that meet these criteria should adopt tip & tail". For instance, I believe Apache Commons projects are popular but use one-size-fits-all (here's Commons Lang: <a href="https://commons.apache.org/proper/commons-lang/changes-report.html">https://commons.apache.org/proper/commons-lang/changes-report.html</a>). Do you want them to grow a tail (sorry, couldn't resist)? Hibernate currently seems to have just one tail (<a href="https://hibernate.org/orm/releases/">https://hibernate.org/orm/releases/</a>). Do you want them to get another one? </div><div><br></div><div>Neither was there what I'd call a measureable goal, like "When Java 29 is released in September 2027, 80% of the top 100 Java libraries on Maven Central will use tip & tail". Unlike Java version adoption, you could actually measure this rather easily, if the Maven Central folks give you their top 100 list.</div><div><br></div><div>I'm sorry if I'm asking for details here. Maybe these details will come later. My first reply on this thread was, "How do you define success? And how do you measure it?" I'm asking because if you can't answer both questions, then how do you know the change you want is really happening?</div><br><blockquote type="cite"><div><div>If there's only one tail, and it's permanently abandoned in order to concentrate all effort on tip releases going forward, then the library isn't following a multi-train release model anymore, let alone T&T.<br><br>In order to claim you're doing T&T, you need to provide a tail that meets the needs of stability-focused users over an extended period. Some libraries might be able to fork and maintain a long-running tail (that outlives subsequent tips) every two years like clockwork. Other libraries might only be able maintain such a tail for a single notable historical release, and without being able to commit to when the tail releases will occur. In some domains, it might be OK if a library has feature-driven tip releases that appear every few years, plus a single tail train that makes releases infrequently (such that, for some time after a tip release, it's not clear if the tail is going to outlive the tip). This lack of timeliness might not be ideal for tail users, but it might be the reality for a library with limited maintenance resources.<br><br>(We're reaching the margins of multi-train development now. If even the low-cost T&T model can't keep a tail train maintained as tip releases come and go, then the library may as well give up on trains and declare itself one-size-fits-all. The users focused on stability will be disappointed, but no release model can conjure resources from thin air.)<br></div></div></blockquote><div><br></div>I think there some is crucial information in here. I find the tail train explanations to be a weaker part of the JEP.<br></div><br><div><div><br></div><div>Regards,</div><div>Karsten Silz</div></div></body></html>