Version-string schemes for the Java SE Platform and the JDK
mark.reinhold at oracle.com
mark.reinhold at oracle.com
Thu Nov 2 15:10:48 UTC 2017
Thanks to those who read what I wrote  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 .
(-) In the absolute time-based schemes, the gaps between successive
version numbers make it awkward to specify versions to tools and
Additional alternatives to consider:
(D) A dual scheme, in which there's both a "marketing" version and a
"technical" version .
On this suggestion I agree with another respondent -- we've been here
before, and it would add more confusion than it's worth .
(E) A sequence of incrementing numerals, much like JEP 223, plus the
release date .
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
Up next: A specific proposal ...
More information about the jdk-dev