An impassioned plea on version numbers
peter.lawrey at gmail.com
Tue Sep 26 12:33:50 UTC 2017
A single number approach might be
Given we have 3 digit updates now it might not matter as much.
However 10, 11, 12 seems like a fine suggestion.
On 22 Sep. 2017 21:04, "Stephen Colebourne" <scolebourne at joda.org> wrote:
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:
1) The vast majority of existing code that needs to know the version of
Java only cares about the major digit. For example online CI like
Travis/Shippable, build tools like Maven, community projects that target
different behaviour to different releases, all only consider the version to
be a single number. This is far more disruptive than changing 1.9 to 9
because these pieces of code would need to handle two important numbers (18
and 3), not one.. Forcing all this code to change is simply not a good
2) No version is more important than any other going forward in terms of
features. A new language change (the most disruptive) could occur in March
or September. It will require a developer to specify two numbers (18.3) to
say what release LVTI is in for example. Given the strong link to semantic
version numbering in developers minds, the numbering scheme simply does not
make sense. A major new language change in a minor point release??!! Being
able to say quickly and easily what version a new language feature is in is
vital, and 18.3 / 18.9 obscures that horribly.
3) While the LTS release is important to Oracle and big business, it will
be pretty unimportant to the community. It should not be the basis of the
4) The proposed scheme appears to be a lot about forcing through the change
within Oracle processes, based on the idea that if it is named after a
month then no one can ask it to slip. However true that fear might be, it
does not justify developers having to face a sub-standard version scheme.
5) Java is not an OS like Ubuntu. The version of Java is referred to all
the time - it is front and centre in discussions about Java. Even
recruiters talk about it! It needs to be simple and straightforward for all
the tasks it is used for - a year/month scheme is unusual and unexpected.
I propose that versions should simply increase incrementally.
March 2018 - v10
September 2018 - v11
March 2019 - v12
September 2019 - v13
and so on.
More information about the discuss