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

[Nicolai Parlog]

 Hi,

many repliers see no reason to change the version-string scheme. I do.

Mark wrote[1]:

> Given the new release model, what is the best version scheme
> for the Java SE Platform and the JDK?

Since Java has a brand new version-string scheme[2], it makes sense to
put this question into that context and rephrase it to:

> Given the new release model, does JEP 223 still define the
> best version scheme for the Java SE Platform and the JDK?

Or even:

> Given the new release model, which (possibly implicit)
> assumptions of JEP 223 no longer apply?

I think the answer lies here:

> `$MAJOR` --- The major version number, incremented for a major
> release that contains significant new features as specified in
> a new edition of the Java SE Platform Specification

With two to three years between major releases the assumption that they
warrant a major version number increment is legit. Consequently, JDK
engineers, JCP observers, and the general public know early on what the
new version will be called and can use it in repository trees, issue
trackers, announcements, discussions, etc.

By releasing a new "major" version every six months it seems possible
that, following JEP 223, some of them do not earn a major version number
increment. (If everybody's sure that every six-month release "contains
significant new features", then the rest of my argument is moot and JEP
223's scheme has no weakness after all.) The new version would be
decided upon when the release enters rampdown phase, approx. three
months before the release. Forecasting names for the release after next
or even further becomes very unreliable.

This is obviously a severe inconvenience for the people working on Java
and I am sure that, out of necessity, they will start referencing
versions by their release date. Where they used to discuss "Will
$feature make it into Java 10?" it will now be "Will $feature make it
into the September 2018 release?" Similarly if repository trees are
named by releases (will that still happen?) or issues are targeted for
releases that are more than three months into the future, they _have to_
use release dates.

When I began writing this mail, I only saw that as a possibility, but by
now I have convinced myself that "internally" (at Oracle and on the
mailing lists) releases will mostly be referenced by date unless the new
version-scheme is 100% predictable (which JEP 223 isn't).

(Interestingly enough, that puts me at odds with at least two proposals,
which argue to use release dates externally and "proper semver"
internally. I think that puts the cart before the horse because
_internal_ use is driving the "release date as version string" idea, not
external.)

Magnus wrote[3]:

> The question you're discussing here is "what is convenient for the
developers and release managers of OpenJDK", not "what is convenient for
the users of OpenJDK". The number of the former outweight the latter in
orders of magnitute, and so it's the only impact that's relevant in this
discussion.

The apparently clear distinction between "JDK developers" and "JDK
users" is misleading. How do users learn about the new release? By
reading the great "State of the ..." documents (written by JDK
developers), the mailing lists (JDK devs and those close by),
articles/tweets/... (same people), or by attending talks (same people).
The vernacular of referencing versions by their release date will seep
into "user space" and this is even advisable when talking about releases
more than a few months into the future.

(Nota bene: We just decided that we will move our product's baseline
from Java 8 to the Sep 2018 release. What will it be called? Nobody
knows, but we nonetheless have to reference it when documenting that
decision.)

Taken together, I'd say that does not render the "orders of magnitute"
argument moot, but it does put it into perspective and should make clear
that no matter what version-scheme is eventually picked, users will hear
a lot about those release dates anyway.

With all of that said, this is not an argument for naming versions
purely after release dates. The situations I described so far just mean
that release dates will become much more important in the months leading
up to and immediately following a release. And I think that makes it
fair to consider whether the release date is the better version.

Personally, I still think it isn't. I'm convinced that in the long term
users will be better served with a well-known version-string scheme like
the one JEP 223 defines, but others have made that argument already.
Ideally a variant could be found that marries the two pieces of
information (release date and semantic version), but (A) I have no good
idea and (B);

> Please don't say which version-number scheme you prefer for
> Java SE and the JDK.

:)

so long ... Nicolai


[1]: http://mail.openjdk.java.net/pipermail/jdk-dev/2017-October/000018.html
[2]: http://openjdk.java.net/jeps/223
[3]: http://mail.openjdk.java.net/pipermail/jdk-dev/2017-October/000059.html



-- 

PGP Key:
    http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509

Web:
    http://codefx.org
        a blog about software development
    https://www.sitepoint.com/java
        high-quality Java/JVM content
    http://do-foss.de
        Free and Open Source Software for the City of Dortmund

Twitter:
    https://twitter.com/nipafx