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

[David Lloyd]

On Thu, Oct 19, 2017 at 10:08 AM,  <mark.reinhold at oracle.com> wrote:
> to degenerate into bike-sheds [3][4].

Disagree.  The bike-shed metaphor specifically relates to topics of
great complexity, whose less-important side aspects (the bike shed)
are debated rather than the core topic because few understand the core
topic (the "atomic plant").  Version discussions don't fall into this
category - quite the opposite actually: there are a vast number of
people with fully informed background and experience on the core
topic: as software engineers, most of us are building this particular
atomic plant on a daily basis.

OTOH if the release process is the atomic plant, then surely the idea
of changing the release numbering was a bikeshed topic to begin with,
and it should have been left as-is.

> axes of information, which can answer different but often related questions:

I would add these axes, which are frankly typically the only two that
my users normally ever seem to care about:

  - Order -- "Did this version come before or after that one?"  This
is a separate issue from "Time", which is a special case of "Order".

  - Sequence -- "What versions came immediately before or after this
one?  If my fix doesn't get into this release, what is my next chance?
 How many versions between this one and that one?"

> Convention also dictates that version numbers be pointwise totally ordered, that they increase monotonically over time

This is less of a convention and more of a hard requirement that
speaks to the definition of what "version" even means.  Syntax aside,
versions really *must* be totally ordered or they are meaningless:
machines cannot really make much use of them, nor can humans, beyond
basic identity comparisons.

> Some considerations for each axis, in turn:
>[...]
> These considerations leave us with the final axis, time, as the leading
> candidate for the primary basis of Java SE and JDK version numbers.

Due to neglect of the other two axes I mention above, I challenge this
conclusion.  Also, even without the aforementioned additional axes, I
would argue that there would still be no logical demand to use the
remaining axis as the primary basis for versioning.  You *could* do
it, but there seems to be no logical path that would say you *must* do
it.

> In the abstract, absolute times have three attractive properties:
>   - Absolute times reflect release dates, so they make it clear to all
>     involved -- both developers of the JDK and users of the JDK -- that
>     these are time-based releases.  There can be no question of delaying
>     a release in order to add "just one more feature" to it.

This brings to mind the famous quote attributed to Stroustrup
regarding technical solutions to social problems.  There should never
be a question of delaying a release: this is because the release
manager says "This release will not be delayed".  If you're at a stage
where the version number is the pivotal argument to prevent this, then
I'd say there is a broken process that needs to be amended, because
experience tells me that if the delay mentality exists, it will
surface regardless of this (or really any) type of consequence.

If date-based version numbers are used, if/when the social contract is
violated such that a release goes out when it shouldn't (either late
or early), you end up either with an inconsistent date/version (if the
version is chosen based on the actual release date) or a version
number which is just plain wrong (if the version does not match the
incorrect release date).  Using simple sequential numbers means that
if/when the human process is broken, the technical result (which is
enshrined for eternity) will still be self-consistent and correct.

Also, this problem's relevance is generally limited to those who
contribute to the JDK, whereas the users of the JDK's version scheme
are primarily not JDK contributors, likely by a ratio of at least
1,000:1 (if not more).

>   - Absolute times make it easy to figure out how old a release is, so
>     that as a user you can understand how far behind you are.

The most useful answer to the question of "how far behind am I?" is
usually not a number of months or years, but a number of releases.  Or
sometimes, a set of features missed, which is also a function of the
number of releases, not the amount of calendar time.

>         eventually have very large version numbers, as in (A).  In the
>[...]
>         latest stable release is numbered 1520.6 [b].

As an aside, it's not clear why "very large" version numbers would
themselves be any sort of disadvantage or problem.  We only care about
the dates of those releases for historical or social reasons, not
technical reasons.  Using dates here (whether absolute or relative)
obscures these bits of information without giving the user anything
enduringly useful in return.

>   - Are there additional pros and cons to the alternatives listed above?

The cons of using time at all are that that you get a semblance of
order (if you stick with 4-digit years, grandkids or not!) but no idea
of  sequence.  The question of "when was this release cut?" is not
nearly as frequently asked as "what release came before/after X?" or
"how many releases different am I?".

>   - Are there additional alternatives worth considering, and if so what
>     are their pros and cons?

A plain sequence starting from 10 and counting up with each primary
release, not encoding any date information.

Pros: sequence, order, consistency with the current scheme, not
confusing to users, consistency with the majority of existing
software, compatibility and consistency with JPMS and most other
existing version schemes, general predictability (based on cadence)
approximately when a release will appear or has appeared without
resorting to difficult things like Google

Cons: inability to use the version scheme as a social lever over the
JDK release manager, extra work to look up the exact date when a
release was or will be performed if one cares about that information

>   - Are there specific experiences with other projects or products that
>     can inform this choice?

The vast majority of software in existence (including the JDK itself)
uses a monotonically and sequentially increasing primary version with
success.  The costs and risks of revisiting this choice with a novel
scheme at this time seem to outweigh the benefits to me.

-- 
- DML