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.
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:
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.
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.
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.
Some of the goals of this numbering scheme are:
Any bugs targeted for 7u14 have been reassigned to 7u40.
Security alerts may be odd or even as necessary.