Thanks to those who read what I wrote [1] and took the time to reply.First, some general points: - Version numbers affect everyone. They're relevant not just to developers who work on the JDK, but to all who use it. The Java platform is not simply a library whose users can adjust to new releases by updating a few dependency constraints. It is, rather, the foundation of an enormous ecosystem of libraries, frameworks, and tools, some of which may require or benefit from upgrades when a JDK release ships. We all need sensible version numbers in order to plan ahead for upgrades and migrations. - Encoding the compatibility or significance of a JDK release in its version number is a recipe for confusion. The compatibility level of a release, or the significance of the changes within it, is not known until near the end of the release's six-month development cycle. Everyone who works on the JDK, or builds or uses components on top of it, would have to speak initially of the release date and then switch to speaking of the assigned version number. Those who maintain libraries, frameworks, and tools would have to be prepared to change code that inspects version numbers late in the JDK release cycle. - Encoding the support lifetime of a release in the release's version number is also a recipe for confusion. The version number of a release is meant to be the same across all implementations of that release. The support lifetime of a release can, however, vary from implementor to implementor, and the support lifetime of a release from a single implementor can change over time. (It could make sense to encode support lifetimes elsewhere in the overall version string, but not in the version number itself.) - I didn't suggest a time-based version scheme in order to work around some internal Oracle process problem. Oracle's management is fully committed to the six-month, time-based release model.Now, to summarize new information.Additional disadvantages of some of the alternatives that I listed: (-) A two-digit absolute time-based scheme would make it difficult to switch back to a more-traditional scheme, should we ever wish to do that [2]. (-) In the absolute time-based schemes, the gaps between successive version numbers make it awkward to specify versions to tools and APIs [2].Additional alternatives to consider: (D) A dual scheme, in which there's both a "marketing" version and a "technical" version [3].On this suggestion I agree with another respondent -- we've been herebefore, and it would add more confusion than it's worth [4]. (E) A sequence of incrementing numerals, much like JEP 223, plus the release date [5].Encoding these two types of information in version strings seems likeoverkill, when one can be derived from the other. It may, however, beuseful to convey the release date separately to indicate not just the ageof the release but also as an indicator of its security level relative tosome baseline.Up next: A specific proposal ...- Mark[1]http://mail.openjdk.java.net/pipermail/jdk-dev/2017-October/000007.html[2]http://mail.openjdk.java.net/pipermail/jdk-dev/2017-October/000030.html[3]http://mail.openjdk.java.net/pipermail/jdk-dev/2017-October/000031.html[4]http://mail.openjdk.java.net/pipermail/jdk-dev/2017-October/000033.html[5]http://mail.openjdk.java.net/pipermail/jdk-dev/2017-October/000028.html