JDK 10: What we know so far
© Shutterstock / patpitchaya
“This scheme will often define version numbers that are not much different from what the JEP 223 scheme would have defined,” Mark Reinhold wrote in a message to the OpenJDK mailing list announcing JEP 322. That said, let’s see how they fixed one of users’ biggest problems, namely to [easily] figure out how old a release is.
Time-based release versioning: The story so far
It ain’t over until the fat lady sings. The story goes like this: three months ago, Mark Reinhold, the Chief Architect of the Java Platform Group at Oracle, proposed that the Java SE Platform and the JDK go from “the historical feature-driven release model to a strict, time-based model with a new feature release every six months, update releases every quarter, and a long-term support release every three years.”
Suffice it to say that people didn’t like the idea — Stephen Colebourne even wrote a plea “for sane Java version numbers such as 10, 11, 12”. However, as Falk Sippach pointed out in a recent interview, “no one knows whether it really is going to go this way.”
From JEP 223 to JEP 322
Turns out Falk was right all along: Oracle offered three alternatives and presented a specific proposal in early November. Mark Reinhold’s proposal was “even closer to the current scheme as defined in JEP 223 and less likely to surprise, and should be easier to adopt.”
After reasonable objections were raised against this scheme [March 2018 release would be 18.3, the September release would be 18.9 etc] we reviewed the various types of information encoded in version numbers and suggested some alternatives, then summarized and responded to the discussion that followed, and finally published a proposal that was well received and hence became the basis for this JEP.
It’s time to say goodbye to the scheme introduced by JEP 223 since it’s no longer “well-suited to the [six-month cadence] future”. Therefore, the main change is “to recast version numbers to encode not compatibility and significance but, rather, the passage of time, in terms of release cycles.”
According to Mark Reinhold, “this is a better fit for time-based release models since each release cycle, and thus each release’s version number is always known well in advance.”
— Mark Reinhold (@mreinhold) December 4, 2017
- Recast the version-number scheme introduced by JEP 223 so that it better fits time-based release models that define feature releases, which can contain new features, and update releases, which only fix bugs.
- Allow for time-based release models other than the current model, with a different cadence or with interim releases smaller than feature releases but larger than update releases.
Preserve compatibility with the overall JEP 223 version-string scheme.
- Make it easy for a developer or end user to figure out how old a release is so that they can judge whether to upgrade it to a newer release with the latest security fixes and, possibly, additional features.
- Provide a way for an implementor to indicate that a release is part of a series of releases for which the implementor offers long-term support.
- Provide a way for an implementor to include and display an additional, implementor-specific version string in order to align a release with related products.
$VNUM — The first four elements are interpreted as follows:
$FEATURE — The feature-release counter, incremented for every feature release regardless of release content. Features may be added in a feature release; they may also be removed, if advance notice was given at least one feature release ahead of time. Incompatible changes may be made when justified. (Formerly
$INTERIM — The interim-release counter, incremented for non-feature releases that contain compatible bug fixes and enhancements but no incompatible changes, no feature removals, and no changes to standard APIs. (Formerly
$UPDATE — The update-release counter, incremented for compatible update releases that fix security issues, regressions, and bugs in newer features. (Formerly
$SECURITY, but with a non-trivial incrementation rule.)
$PATCH— The emergency patch-release counter, incremented only when it’s necessary to produce an emergency release to fix a critical issue. (Using an additional element for this purpose minimizes disruption to both developers and users of in-flight update releases.)
The fifth and later elements of version numbers are reserved for use by downstream consumers of the JDK code base. The fifth element may be used to, e.g., identify implementor-specific patch releases.
This is how the elements will look like under the six-month release model
$FEATUREis incremented every six months: The March 2018 release is JDK 10, the September 2018 release is JDK 11, and so forth.
$INTERIMis always zero, since the six-month model does not include interim releases. We reserve it here for flexibility, so that a future revision to the release model could include such releases and say that JDK
$N.2are compatible upgrades of JDK
$N. As examples, the JDK 1.4.1 and 1.4.2 releases were, in essence, interim releases, and would have been numbered 4.1 and 4.2 under this scheme.
$UPDATEis incremented one month after
$FEATUREis incremented, and every three months thereafter: The April 2018 release is JDK 10.0.1, the July release is JDK 10.0.2, and so forth.
In short, “this scheme will often define version numbers that are not much different from what the JEP 223 scheme would have defined.”
Read the entire announcement here.