"To avoid the confusion caused by renumbering releases", Oracle has announced that it is adopting a new numbering scheme for JDK 5.0, JDK 6 and JDK 7. Minor Java releases are divided into planned Limited Update releases that include non-security related bug fixes and occasional new functionality, and Critical Patch Updates (CPUs) that only include fixes for security vulnerabilities. The increasing frequency of security releases means that planned releases occasionally have to be re-numbered. This causes problems for Oracle since it means fixes and enhancements can't be assigned to specific releases in bug tracking systems.
To work around this Oracle has decided that:
- 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.
Whilst noting that he wasn't involved in the discussions around this, Oracle's Phil Race, who has been an engineer on the Java client team at Sun/Oracle over 12 years, provides some more details on the OpenJDK mailing list
There's become something of a convention that security update releases are odd numbers and other releases are even numbers. I'm not sure how important that is to the outside world but if two security releases happen without a release in between you need to decide if you want to break that convention.
We also had a lot of confusion arise from the need to do a few unplanned releases. Builds of 7u14 existed, bugs were marked as fixed in that release, reports, stats, etc all referred to that release but all that data is now wrong, and that work is now going to (hopefully) see the light of day in 7u40. In the interim, internally and externally people couldn't understand why a bug supposedly fixed in 7u14 was reproducible in 7u17. So leaving a very generous gap between non-security release numbers means we should not have to do the re-numbering on the fly.
Leaving gaps between planned security release numbers mean there's already a place set aside in case any unplanned release has to happen. Keeping the odd numbering convention for security release uses up more numbers. So that's how you end up with such inscrutable jumps in numbers.
eg :
7u15 was a planned security release
7u17 was unplanned, using a reserved number (I think)
7u19 was reserved just in case, but not needed
7u21 was a planned security release
and so forth ...
Oracle notes that a more elegant solution would require the changing of the version numbering scheme to accommodate different kinds of changes (for example by using 7u44-2 ). However this cannot be implemented outside of a major release, since doing so might break existing code that parses version strings (possibly including the Java auto-update system), in a way vaguely reminiscent of what happened when it changed the company name from Sun Microsystems to Oracle. Moreover, it is unlikely to make the change in time for the much delayed Java 8 release.