Alongside other major changes, the recently released Java 9 also introduced a new versioning scheme. This scheme is based on JEP 223 and was intended for future releases of the Java platform itself.
However, almost immediately after the release Mark Reinhold, Java's chief architect, announced a brand new proposal for changing the version scheme again and adopting a strict, time-based release model.
The main goals of the JEP 223 based versioning scheme are:
- To make the versions easily understandable by humans
- Align with current industry practices
- Be adoptable by existing packaging systems and platform-deployment mechanisms
- Eliminate the current practice of encoding two types of information in one element of the version string
- Provide a simple API for version-string parsing, validation, and comparison.
Java 9 release notes describe the new version-string format as follows:
$MAJOR.$MINOR.$SECURITY.$PATCH
- $MAJOR version number is incremented for a major release, which contains significant new features as specified by Java SE Platform specifications. Features in major release are planned and announced well in advance.
- $MINOR version is incremented for each minor update, such as bug fixes, revisions to standard APIs, or implementation of features outside the scope of the relevant platform specifications.
- $SECURITY version number is incremented for a security-update release, which contains critical fixes to improve security.
- $PATCH version number is incremented for a release containing security and high-priority customer fixes that have been tested together.
Reinhold proposed to change this scheme in favor of a time-based release model. He argues that the Java SE platform and JDK have evolved in large, irregular, and somewhat unpredictable steps over the past twenty years.
Each feature release has been driven by a few significant features and the release schedule is generally adjusted as needed, in order to accommodate the development of those features. Reinhold says that such a release schedule is out of date, now that Java competes with many modern platforms which evolve at a more rapid pace.
Reinhold: Taking inspiration from the release models used by other platforms and by various operating-system distributions, I propose that after Java 9 we adopt 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.
According to this model, developers who prefer rapid innovation can use the most recent feature release or an update release and move on to the next one when it ships. Enterprises that prefer stability, can instead use the current long-term support release. They can plan ahead to migrate from one long-term support release to the next.
The proposed version string would be of the form
$YEAR.$MONTH
So the March 2018 release would be 18.3, and September 2018 release would be 18.9. Reinhold defended the use of absolute times for versioning in a jdk-dev mailing list post as follows:
Reinhold:
- Absolute times reflect release dates, so they make it clear to all involved -- both developers of the JDK and users of the JDK -- that these are time-based releases. There can be no question of delaying a release in order to add "just one more feature" to it.
- Absolute times make it easy to figure out how old a release is, so that as a user you can understand how far behind you are. Relative times require you to know what the time units are, and when these time-based version numbers were adopted.
- Absolute times are independent of the release cadence. If in a few years we switch to an even faster cadence, say every three months, then an absolute scheme would need no change but a relative scheme would need to be revised with a new time unit and starting point.
Absolute times versioning model proved to be not popular amongst the community and Reinhold produced a revised proposal in a mailing list post. The revised proposed scheme is similar to the one originally proposed in JEP 223 and represents a compromise between the two viewpoints.
The current proposed form of the new version-string format as it stands is:
$FEATURE.$INTERIM.$UPDATE.$EMERG
- $FEATURE counter is incremented every six months regardless of release content.
- $INTERIM counter is incremented for non-feature release that contain compatible bug fixes and enhancements but no incompatible changes. This counter is always zero for the current six-month release model.
- $UPDATE counter is incremented every three months for compatible update releases that fix security issues, regressions, and bugs in newer features.
- $EMERG counter is incremented only when it's necessary to produce an emergency release to fix a critical issue.
This is primarily a time-based scheme. $FEATURE is incremented every six months regardless of release content and, for each feature release, $UPDATE is incremented every three months.
In this model, the next feature release (previously called major release) of Java would still be Java 10, and it would be produced in March 2018, with Java 11 following in September 2018. The proposal remains under active discussion with a final decision and announcement expected soon.
