<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Hi Karsten,</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
I will share my personal understanding on this topic.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
For when tail releases occur, I think the presence of incompatibilities, intentional or accidental, is usually a major factor.  For feature-based versioning, such as semver (<a href="https://semver.org" title="https://semver.org">https://semver.org</a>), it
 makes sense to create new tails when your MAJOR version bumps as it breaks backward compatibility.  It also makes sense to create new tails with particular MINOR version bumps, because sometimes new functionalities may bring unforeseen backward compatibility
 problems.  For time-based release, like that for OpenJDK, the promotion of tail can also be based on features; for example, when JDK 9 moved around sun's internal implementation packages to jdk.internal, libraries break because their (technically invalid)
 dependencies changed, and some distributors offered to make 8 a tail.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
For when tail releases are terminated, I think it is mainly due to the maintenance costs.  For example, as time goes on, the backport of security or bugfixes can reduce as the codebase diverges, and only the most critical of the bugfixes may be backported. 
 For example, between JDK 11 and JDK 17, I believe there had been other companies that tried to maintain longer tail trains for some versions, but they ultimately gave up due to the costs.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
For publishing a bugfix on the tip train, sure it is totally possible!  For example, if a bug is fixed on JDK repository's master branch, it will be included in a new build.  But this means that the bugfix is distributed with risky features, which can impact
 some users.  In fact, a majority of JDK bugs are never backported to tail releases, and some bugs are only backported after there has been a request from tail release users.  Such an ideology of careful backports can be seen from the OpenJDK's JDK-update project
 process of backport approval. (See the process at <a href="https://openjdk.org/projects/jdk-updates/groundrules.html">
https://openjdk.org/projects/jdk-updates/groundrules.html</a>)</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Regards,</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Chen Liang</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> jdk-dev <jdk-dev-retn@openjdk.org> on behalf of Karsten Silz <karsten.silz@gmail.com><br>
<b>Sent:</b> Sunday, November 3, 2024 1:55 AM<br>
<b>To:</b> jdk-dev@openjdk.org <jdk-dev@openjdk.org><br>
<b>Subject:</b> Re: New informational JEP: 14: The Tip & Tail Model of Library Development
</font>
<div> </div>
</div>
<div style="line-break:after-white-space">
<div>I have two questions about tail releases.</div>
<div><br>
</div>
<div>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."</div>
<div><br>
</div>
<div>Second, can a library publish a bug fix release on the tip train? Or is that automatically a tail release?</div>
<div><br>
</div>
<div><br class="x_Apple-interchange-newline">
<span style="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; text-decoration:none; display:inline!important; float:none">Regards,</span><br style="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; text-decoration:none">
<span style="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; text-decoration:none; display:inline!important; float:none">Karsten
 Silz</span><br style="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; text-decoration:none">
<br style="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; text-decoration:none">
</div>
<br>
</div>
</body>
</html>