Version-string schemes for the Java SE Platform and the JDK
scolebourne at joda.org
Wed Oct 25 11:45:24 UTC 2017
On 19 October 2017 at 16:08, <mark.reinhold at oracle.com> wrote:
> - Compatibility -- "Will my code break if I upgrade to this release?"
> - Significance -- "How different is this release from what I have now?"
> - Security -- "Does this release contain new security fixes?"
> - Support -- "For how long will this release be supported?"
> - Identity -- "On exactly which build was this bug reported against?"
> - Time -- "When did this release ship? How far behind am I?"
Lets rule out axes that are not important first. "Significance" is the
same as compatibility in most cases. "Security" is orthogonal.
"Identity" should be dealt with by any sensible version scheme. "Time"
is of no importance to any library/platform I've ever dealt with - you
simply look it up if you need to care.
Compatibility must be the key driver for versions. The broad rules of
semver (semantic versioning) are widely adopted and understood within
the software industry and any departure from it should be treated with
great scepticism. Note that when I mention semver I consider it to be
a general framework rather than a strict set of rules to follow - not
everyone will make that distinction.
As such, there will be general agreement around a number following the
pattern x.y where the first number is the major version and represents
the fundamental compatibility level of the software.
The proposal 18.3 / 18.9 / 19.3 etc. is extremely objectionable
because it gives the appearance of being a semver when it isn't. The
issue is that a major change may occur in 18.9, which is 100% wrong in
semver-style versioning. It gives the appearance of having made a
major breaking change in a minor release - a massive no-no.
As such, all version schemes using two separate digits where a major
change happens with only the second digit changing MUST BE REJECTED.
If a release can contain a major change then the first version number
must change (unless the beta approach is used, see below).
A "major change" must include at least language enhancements,
method/class/module deletion and class file version change. As I
understand the next few releases, each release will have at least one
of these, and as such each one triggers a major release which requires
the first "major" digit of the version number to change.
A "minor change" would include adding a new method to an existing API,
adding a new class/type, adding a new module. All of these would be
fine to be accepted in the second "minor" digit of the version number
with the "major" digit staying the same.
> ...the set of features is not known
> until late in each release cycle, after the final feature is merged.
> ... then would the March 2018 release be version 9.1, or 10? We
> can't know until some time in December 2017, when the release closes
> for stabilization.
Personally I don't think this is a major problem. In most systems I've
worked on you allocate the number as being minor until someone commits
a major change and then bump it to major. ie. March 2018 would be
named 9.1 until a major change is committed when it would then be
changed to 10. However, given how rare a minor-only release is likely
to be, I don't think this is worth pursuing.
> - The support lifetime of a release is useful information, but it's not
> appropriate to encode that into the version number of the Java SE
> Platform or the JDK. The version number should be identical in all
> implementations of a given release, but the support lifetime of a
> release may vary from implementor to implementor.
The "Support" axis is the wildcard in the whole discussion. While it
is true that in theory an implementor might provide LTS for release
other than those that Oracle provides LTS for, there is a huge open
question of whether they will, or whether it would be appropriate for
them to do so. This is a huge missing piece of the puzzle on
versioning, and can radically change the result of the discussion:
For example, if Oracle and the community were to agree that LTS
releases are the new "real" releases, then the most appropriate
version scheme would be one that reflected that:
9 (Set 2017) - now designated an LTS release
10-BETA-1 (Mar 2018)
10 (Sept 2018) - an LTS release (example)
11-BETA-1 (Mar 2019)
11-BETA-2 (Sep 2019)
11-BETA-3 (Mar 2020)
11 (Sep 2020) - an LTS release (example)
This is really clear as to what the releases are - beta releases in
preparation for an LTS. It is also much clearer that you shouldn't use
them once the next beta is out. Obviously some organizations reject
using beta code in production, but they would probably be the same
organizations that will only use an LTS anyway.
To adopt this requires broad agreement from all OpenJDK participants
that LTS releases are the only full releases (and implied in that is
probably that Java SE 9 is a "real" release simply because of its
> These considerations leave us with the final axis, time, as the leading
> candidate for the primary basis of Java SE and JDK version numbers.
As indicated above, I (and many others) reject this conclusion, and
thus most of the rest of the arguments in the email are null and void.
> - Are there additional pros and cons to the alternatives listed above?
(B) fails the essential test that a major change MUST NOT occur in the
second digit. As such it is immediately rejected.
(A) and (C) do meet the test, although the reason suggested to use the
age in months as the second digit is both weak and unnecessary. A
third digit can represent emergency releases, or the update releases
could go in units of 20 as now.
(A) is weird because the number is so large. Developers talk about the
Java version they use all the time, and this would make those
discussions painful. And since the date of a release is in general
completely unimportant, it should be rejected anyway.
The description of (C) is weird because of the nonsensical attempt to
link the first number in the scheme to time. If it is just a number
then the potential problem of 3 monthly releases goes away.
> - Are there additional alternatives worth considering, and if so what
> are their pros and cons?
I've outlined the BETA scheme above. To me it most clearly represents
what the wider community would expect, as I think if you asked them,
only LTS releases with support would count as "real" releases worthy
of changing the first digit, and all other "releases" are simply betas
working towards the LTS. Note that this implies that no piece of
functionality can be deprecated in BETA1 and removed in BETA2, which
would be a sensible approach anyway.
The main con of the BETA scheme is that it encodes a specific LTS
model into the version scheme. And I suspect there might be some
pushback on the principle of downgrading 6 monthly release relative to
the LTS ones. In my view this is actually just a statement of fact -
as without support you are forced to upgrade making them clearly a
lower grade of release.
Now, if RedHat or someone else were to publicly say that they will
support every 6 monthly release for a 5 year period, then the BETA
scheme doesn't work. But IMO, the community would be better served by
a widely agreed LTS release every 2 to 3 years, with BETA releases in
between for advanced users.
If the BETA scheme is rejected, the default should be to continue
using the existing scheme - a simple incrementing number - 10, 11, 12,
etc. This fits with JEP 223, causes no particular pain or issues with
the wider community. The pros of this scheme are that it is well
known, well understood and already works. It has the con that it
doesn't help Oracle ship software on time, but thats not something
that the version scheme should care about (and might even be viewed as
a positive on rare occasions). See also David Lloyd's pros/cons of the
current incrementing number scheme.
> - Are there specific experiences with other projects or products that
> can inform this choice?
Java is a software platform, not an OS. It is closer to Apache Tomcat
or Spring Framework than Ubuntu. So numbering schemes used by open
source projects and maven central (almost all based on semver) should
be the guide here.
As others have emphasised, JEP 223 has discussed and decided this
issue. There would have to be a very good reason to change the
The only justification I can possibly see is that there are now two
grades of release - intermediate (no support beyond 6 months, thus
forced upgrade) and full (LTS). None of the proposals in the original
email represent that key distinction - the BETA scheme above does of
Unless there is wide agreement on the concept of beta releases leading
to a full LTS release, the only rational choice it to retain the
existing JEP 223 numbering scheme, thus March 2018 is v10 and
September is v11.
More information about the jdk-dev