Version-string schemes for the Java SE Platform and the JDK (original) (raw)

David Lloyd david.lloyd at redhat.com
Thu Oct 19 17:06:26 UTC 2017

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:

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.

--

More information about the jdk-dev mailing list