Proposal: Newer version-string scheme for the Java SE Platform and the JDK

[John Rose]

On Nov 2, 2017, at 2:08 PM, Stephen Colebourne <scolebourne at joda.org> wrote:
> 
> The proposal does not indicate what happens with the class file
> version, but replies on Twitter indicate an intention to update that
> number with each feature release. IMO this would be a mistake, as
> changing the class file number has a knock on effect on a lot of
> low-level downstream tools that often take months to update, with
> nasty impacts on the ability to adopt a feature release. As such, I
> *strongly* argue that the class file version should only change when
> it is required to do so. This will occur naturally when a change is
> merged into master that requires a new version, so there is no impact
> on process that I can see.

This argument works backwards if class file version changes
are likely to occur in each feature release.  In that case, we
have the same knock-on effects as a deterministic lock-step
rule, *plus* unpredictability.

And we *are* likely to be introducing class file format changes
frequently going forward.  The tools will just need to keep
up.  In that environment, would you rather have a predictable
lock-step rule for tool development, or would you still prefer
your scheme, which optimizes for the infrequent "null" change,
at the cost of guessing on a random variable?

From my side of the fence, the process (given the assumption
of frequent changes) is slightly simplified by a predictable class
file version number to integrate against.  Remember that features
are only integrated when ready to release.  For JVM work, this
means changes to classfile format must keep the classfile
version number late-bound, until the integration goes ahead.
It's easier to late-bind against a predictable number.

— John