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

Aleksey Shipilev shade at redhat.com
Fri Oct 20 10:34:11 UTC 2017

On 10/19/2017 05:08 PM, mark.reinhold at oracle.com wrote:

Not everyone likes this proposal, which isn't surprising -- discussions of version-string schemes, much like those of language syntax, often tend to degenerate into bike-sheds [3][4].

To be honest, changing the version scheme again looks like bike-shedding to me. We don't have to reinvent the version scheme that is already widely understood. Especially if the discussion about the version schemes does not indicate there exists the perfect one.

Some considerations for each axis, in turn:

- Compatibility is obviously important -- it's one of the core values of the Java Platform, after all -- but it's problematic in at least two respects and hence not a sound basis for version numbers. First: Compatibility is, itself, multi-dimensional and therefore difficult to encode into a simple sequence of numerals. What counts as an incompatible change?

I am baffled by this. JEP 223 explains what counts as $MAJOR change. Current version scheme puts compatibility on pedestal, and this dubs the project goals. We need more than "it would fit the process [a little] better" to switch from compatibility as major version axis.

Second: The compatibility of a particular release with any of its predecessors depends upon the set of features in that release. In a time-based release model, however, the set of features is not known until late in each release cycle, after the final feature is merged. This complicates discussions of any specific release and the tracking of changes in JIRA and related systems. If, e.g., we use the leading numerals of version numbers to encode compatibility in the usual way, with the first numeral increasing only when incompatible changes are made, then would the March 2018 release be version 9.1, or 10? We can't know until some time in December 2017, when the release closes for stabilization.

This indicates the discrepancy in the release cadence proposal. If we incept the release without knowing what features go in there (which is in line with JEP process), we indeed cannot make a proper designation for that release early. But, this is not the version scheme problem, it is the circularity problem in the process itself, and that problem should be solved there. Switching to whatever versioning scheme that sweeps the process problem under the rug is odd.

Is this the primary motivation for the version scheme change? If so, can we "just" amend the process with "jdkX"/"current"/"head"/"master"-like version that is not sealed until the release contents are finalized?

It feels odd to extend the solution to "we need a name for a pending release that goes out in 6 months because we don't know what compat/security/etc label to apply" to "now we rename all released bits to not to have compat/security/etc labels, forever". In other words, if we have the the temporal problem with pending release, this does not mean we have to switch the versioning scheme for all stable releases.

These considerations leave us with the final axis, time, as the leading candidate for the primary basis of Java SE and JDK version numbers.

Not so fast! The rhetoric of the discussion seems to disqualify previous axes by listing their disadvantages. How is "time" axis exempt from the same scrutiny? The drawbacks seem to be is pretty much everything advantageous of previous axes -- which the discussion already recognizes as important: the encoding of basic compatibility data, basic notion of release significance, security patch level, identity, etc.

The main remaining question, then, is that of how to encode time in version numbers:

Since the rest of the post builds on the questionable premise that "time" is the agreed axis to base the versions on, it makes less sense to discuss that part in detail. It is important to get the basic ideas right, before spending precious time discussing the details.

Thanks, -Aleksey

More information about the jdk-dev mailing list