Java SE - Change in Version Numbering Scheme
Last Updated May 19, 2016
Oracle will change the release numbering for scheduled Java SE releases.
With the recent increase of security releases we have been skipping numbers and have already had to renumber releases 1 . To avoid confusion caused by renumbering releases, we are adopting a new numbering scheme.
Overview
Since the initial release of JDK 5.0, Java update releases have either been Limited Update releases that include new functionality and non-security fixes or Critical Patch Updates (CPUs) that only include fixes for security vulnerabilities. We will continue releasing Limited Update and CPU Java releases, however we are changing the frequency and way in which these releases are numbered:
- Limited Update releases will be numbered in multiples of 20.
- We intend for Critical Patch Updates to continue to use odd numbers. The numbers will be calculated by adding multiples of five to the prior Limited Update and when needed adding one to keep the resulting number odd.
This is best illustrated with an example:
The next Limited Update for JDK 7 will be numbered 7u40, and the next 3 CPUs after that will be numbered 7u45, 7u51, and 7u55. The next release will be a Limited Update 7u60, followed by CPUs 7u65, 7u71, and 7u75.
This numbering scheme will leave several numbers between releases which will allow us to insert releases – for example security alerts or support releases, should that become necessary - without having to renumber later releases.
Updated May 2016
Between the critical update releases of January and April of 2016 we released two critical patch updates. As one of the releases, JDK 8, included a Critical Patch Update (CPU) and a Patch Set Update (PSU), and given our intention of having Critical Patch Updates be odd numbers, we were forced to re-number subsequent releases. To avoid further renumbering we have updated the numbering scheme to add multiples of ten instead of multiples of five to future versions.
Frequently Asked Questions
What versions of the JDK will be impacted by this change?
Oracle will use this new version scheme for JDK 5.0, JDK 6 and JDK 7. Oracle JDK 7 will be provided on the OTN Java SE Downloads page, and end users can visit Java.com to install the latest version of Java 7 on their desktop. JDK 5.0 and JDK 6 are available through My Oracle Support and require a support license.
Is this the long-term solution?
This solution is a compromise to create predictable release numbers for future Java releases, leave version numbers available for unplanned releases needed to address security alerts, and maintain backward compatibility with systems that expect the version number to have only a family number plus a single “update” number. It will be the new standard for the affected version.
A more elegant solution requires changing the version format of the JDK to accommodate multiple types of releases. To avoid incompatibilities with existing code however, a change in the version string format needs to be implemented on a future major Java release and will have to be documented and communicated with adequate time to allow software developers to prepare for the change.
Why is this change necessary now?
Some of the goals of this numbering scheme are:
- Allow us to assign a fix/enhancement to a specific release in our bug systems. To accomplish this all planned releases must have predictable numbers.
- Not break existing code that might parse version strings. This means that we must follow the same format (e.g 7u44 is ok, having something like 7u44-2 is not).
- Leave room for unplanned releases. This together with the above requirement of predictable numbers means that we need to leave “space” between our planned releases for any potential unplanned ones.
I work with OpenJDK and the bugs.sun.com system, what else do I need to know?
Any bugs targeted for 7u14 have been reassigned to 7u40.
Will security alerts always use odd numbers then?
Security alerts may be odd or even as necessary.