<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Hello Mr. Pressler!<div><br></div><div><div>I finally got it: I thought T&T is a rather formal initiative. It's not – it's more of an idea, described for interested parties. Hence, I was after details and rules that may not even exist.</div><div><br></div><div>I want to thank you and Mr. Buckley for answering my questions so patiently. Hopefully, you got something out of it, too.</div><div><br></div><div>
<br class="Apple-interchange-newline"><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; display: inline !important; float: none;">Regards,</span><br style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; display: inline !important; float: none;">Karsten Silz</span><br style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><br style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
</div>
<div><br><blockquote type="cite"><div>On 16. Dec 2024, at 18:58, Ron Pressler <ron.pressler@oracle.com> wrote:</div><div><div><br><blockquote type="cite">On 13 Dec 2024, at 08:10, Karsten Silz <karsten.silz@gmail.com> wrote:<br><br>Hello Mr. Buckley & Mr. Pressler!<br></blockquote><br>Hello Mr Silz!<br><br>I think that at the core of most of your questions (or guesses) is the perception that tip & tail is something more elaborate than it is.<br><br>The only assumption underlying tip & tail is that a software component has two broad classes of users with conflicting needs: one wants new features and one wants to avoid them. The only claim made by tip & tail is that both classes of users will benefit more from the library and at the same time its maintenance costs will be reduced if they’re each served by separate appropriate release trains.<br><br>That — perhaps with an explanation of what is the tip and what is a tail — is a complete and fully actionable description of tip & tail. Everything else is either an implication of that or a “serving suggestion”, and the JEP does offer some implied insight such as pointing out that backports undermine the goals of both groups and so should be minimised (they risk destabilising the tails and take away resources from adding new features to the tip). Further tips and tricks could bring some second-order improvements as they’re learnt over time, but the principle and actions suffice as stated. <br><br>Consider another software development strategy: automated tests. Is saying, “writing and regularly running automated tests prevents the introduction of regressions, the more coverage you have the better, and tests with smaller scopes help localise discovered regressions” not complete, fully actionable, and sufficient to get the benefits even though it doesn’t tell you how many assertions you should have per test and how small the tested units should be? Such details may offer second-order optimisations, but you’ll reap the benefits of the strategy regardless.<br><br>There is nothing you need more than what’s stated in the JEP to implement tip & tail successfully and reap its benefits. Like automated tests, tip & tail is a strategy that quickly makes sense once you think about it for a little bit, but, as with automated tests, you may remain sceptical regarding its cost effectiveness. That is where we come in and say, we were sceptical, too, but we’ve tried it for quite a few tip and tail releases over several years and found it to be cost effective. Of course, we don’t expect that to be enough to remove all scepticism, just as it wasn’t enough to remove all the scepticism around automated tests. It takes a different amount of time for different people to see that such strategies really do decrease costs and increase value compared to what they do now.<br><br>The problem tip & tail seeks to solve is that of how to increase value to users and/or how to lower costs. Asking whether 100% of libraries will benefit from tip & tail is like asking whether 100% of software projects benefit from automated tests whether they think they need it or not. I don’t know the answer to that, but I also don’t see why that question is important. Like automated testing, we believe tip & tail is generally a good idea, and that any library maintainer who thinks value can be increased or costs lowered should consider giving it a try. We don’t hand out certificates and there is no purity test for tip & tail beyond understanding the different needs of the two groups and serving them with different release trains that maximise value and minimise costs. The more you adhere to the principle, the better the user experience will generally be and the lower the cost.<br><br>Now, it is more a theorem than an assumption that upgrading to new versions is relatively cheaper for those who want new features than for those who don't. A project only wants new features if it can make use of them, which means some work is necessarily spent on the project beyond keeping the lights on. This implies that the relative cost of upgrading a library (or JDK) version is necessarily lower for such a project than for one that just keeps the lights on. Whether or not they decide to adopt the new version depends on individual circumstances, but the calculus is necessarily more favourable in actively maintained projects than in legacy ones.<br><br>Does that mean you won’t have users who say they have just enough budget to adopt your new feature X, which they want, but not enough to deal with feature Y, which they don’t want but is also in your tip, and can you backport only A for them please and thank you? Of course you will! What you do then is up to you, but the claim of tip & tail is that in general, splitting your user base into two categories, one that gets new features and one that doesn’t, with as few exceptions as possible, offers the best cost and the best value when integrated over all users.<br><br>You ask about JDK baselines, but none of that is dictated by tip & tail. By splitting the releases for those who want new features and those who don’t, tip & tail automatically gives more freedom to library maintainers in selecting their JDK baseline and makes it less challenging because you can have different baselines that are as low or as high as needed for the feature set in each release train. It is because users who don’t want new features have a separate release train that you can keep it baselined on an old JDK for as long as you want; it is because adopting new JDK releases is necessarily cheaper for users who want new features that you’re free to pick a new JDK as a baseline for the release train intended for those users if it allows you to implement some high-value feature. The JEP gives some examples of baseline choices that tip & tail enables. <br><br>While there’s a nice synergy and when a library and its dependencies (other libraries and/or the JDK) both employ tip & tail, easier baselining of dependencies is merely one consequence of the strategy. Even a C library with no interaction with the OS and no dependencies at all would be able to offer its clients more value and do so at a lower cost with tip & tail than with a one-size-fits-all model.<br><br>Oh, and obviously all popular libraries should support the current (newest) JDK version whether they employ tip & tail or not, as the vast majority of them already do; most of them do so with no work on their part. Conversely (and equally obviously, I think), none of them need to support versions that are no longer maintained.<br><br><br>— Ron<br><br><br></div></div></blockquote></div><br></div></body></html>