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

[Aleksey Shipilev]

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