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

[mark.reinhold at oracle.com]

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