Version-string schemes for the Java SE Platform and the JDK

Thu Nov 2 15:10:48 UTC 2017

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 here
before, 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 like
overkill, when one can be derived from the other. It may, however, be
useful to convey the release date separately to indicate not just the age
of the release but also as an indicator of its security level relative to
some 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