An impassioned plea on version numbers

[Nicolai Parlog]

 Hi,

I appreciate the push towards releasing Java more often and the same
goes for reducing the differences between Oracle JDK and Open JDK as
well as the new licensing details. These are all great decisions moving
Java into the right direction!

Alas, discussions usually focus on disagreements and I want to chime in
on the one thing that I don't agree with: the versioning scheme. Here's
what I wrote elsewhere[1]...

## Disagreement

One problem with year.month is that it looks like semantic versioning
but isn't - 18.9 might have more severe changes than 19.3, yet the
latter incremented the "major version", while the former did not. And it
not only looks like semver, the new Java 9 API even claims it is[2].

Also, every newcomer has to be taught about this, so they don’t go
looking for 18.4. And heavens forbid one release is not on time, so
there’s a 18.4 after all. Or the release months change because nobody
works over the summer, so x.9 never had any interesting new features.
(At least that would reestablish semantic versioning.)

Then there’s the risk of polluting the “version space” with artificially
high numbers. Java already changed the version schema a few times, most
recently on September 21st which was still in the future when this
proposal was made, so it sounds unrealistic to assume that this change
is the last one. But there’s no way but forward from 20.3 — you can
hardly go back to 13, explain to your users why that’s better than 20.3
and then at some point awkwardly jump from 17 over 18.3–20.3 and
continue with 21.

No, I don’t think that’s a good idea.

## Alternative proposals

Why not stick to the current scheme and increment the minor version with
every feature release unless it contains considerable language/JVM
changes, in which case the major version gets bumped.

To pick a few examples from history, Java 6 and 7 might have been 5.1
and 5.2 and, leaving the module system aside, Java 9 could have been
Java 8.1 because the few language changes don’t require the bump to 9.
Examples for major upcoming language changes would be generic
specialization and value types from Project Valhalla. Amber’s proposals,
on the other hand, could be seen on either side — I’d file enhanced
enums and lambda leftovers under minor changes whereas local variable
type inference, pattern matching, and data classes constitute major ones.

This would of course lead to discussions about how much impact a
language change might have and whether it deserves a major version bump
or not, but I don’t see any problems with that — the expected impact of
a feature and how much it would change the code we write are already
being discussed extensively anyways.

If all that’s no good and the year needs to be in there, I have a final
suggestion: Go with year.increment (18.1, 18.2, ...) like JetBrains does
for IntelliJ et al. This would give more leeway for adding, omitting, or
rescheduling releases or the entire release schedule without baking that
into the version.

 so long ... Nicolai


[1]
https://medium.com/codefx-weekly/radical-new-plans-for-java-5f237ab05b0#b2dc
[2]
http://download.java.net/java/jdk9/docs/api/java/lang/Runtime.Version.html#major



On 25.09.2017 15:56, mark.reinhold at oracle.com wrote:
> 2017/9/22 11:04:05 -0700, Stephen Colebourne <scolebourne at joda.org>:
>> While I am super happy to see Java 9 released I remain strongly opposed to
>> the proposed version number scheme from now on. Here is why:
>>
>> ...
> 
> Thanks for your impassioned plea.  You make some reasonable arguments.
> I'll reply at length after JavaOne.
> 
> - Mark
> 

-- 

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