<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;"><blockquote type="cite" style="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;"><blockquote type="cite">On 23 Oct 2024, at 01:15, Alex Buckley <<a href="mailto:alex.buckley@oracle.com">alex.buckley@oracle.com</a>> wrote:</blockquote></blockquote><blockquote type="cite" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br>On 10/22/2024 3:17 PM, Karsten Silz wrote:<br><blockquote type="cite">And then there's this: "a new tail train that they will continue<br>[to] update even after new tip releases are made". This was in the<br>"Tip & Tail" description, so I read it as a definition: "All tail<br>trains must get updates after the next tip release". Non-LTS OpenJDK<br>tail trains don't today. So, a tail train getting updates after the<br>next tip release is a recommendation, not a requirement?<br></blockquote>Again, that part of the Description is high level and needs to be applicable to all libraries. The most interesting scenario for users is where a tail train makes tail releases for many years, long after the next tip release has shipped, so that's how we start describing the T&T model.<br><br>I don't want to weaken the text to accommodate the JDK's T&T implementation -- "a new tail train that they MAY continue to update even after new tip releases are made" -- because this phrasing, while technically correct, will send readers off-track.<br></blockquote><br>Thank you, Alex, for taking the time to answer my questions!<br><br>Here are two observations. There's no call to action here, and there's no need for you to reply.<br><br>First, I'm a JEP newbie. I thought JEPs were like standards, full of MUST and MUSTN'T, SHALL and SHAN'T. I didn't find many of these here. Instead, I found statements that were ambiguous to me. Like this one: "library developers designate a tip release as the start of a new tail train that they will continue to update even after new tip releases are made". I read that as "tail train MUST live beyond the next tip train". But it either isn't a MUST, or it's overruled by this sentence here: "Tip & tail does not specify when or why tail trains are created, nor when or why they are discontinued." As a result, I didn't know how I would move a library to the "Tip & Tail model" just by reading the JEP.<br><br>Second, the JEP cites OpenJDK and Spring Boot as "Tip & Tail" examples. However, the differences between "Generic Tip & Tail", "OpenJDK Tip & Tail", and "Spring Boot Tip & Tail" weren't clear to me from reading the JEP. "OpenJDK Tip & Tail" and "Spring Boot Tip & Tail" also seem identical, except for a different tail train length. If folks just skim the JEP and look at OpenJDK and Spring Boot instead, they may think, "'Tip & Tail' means you have to release a new tip every six months." and turn away. I would have found a table comparing "Generic Tip & Tail", "Spring Boot Tip & Tail", and "Tip & Tail" for a feature-driven library useful. Though not in this JEP – it's already quite long. :-)<br><br><br>Regards,<br>Karsten Silz<br></body></html>