「新番号付けによる混乱を避けるために」とOracleが発表したのは、JDK 5.0, JDK 6、JDK 7用に新しい番号付け方式を採用したことである。マイナーなJava リリースは、計画されたLimited Updateリリース（セキュリティに関係しないバグ修正と時折の新機能を含む）とCritical Patch Updates (CPUs、セキュリティの脆弱性に対する修正のみを含む）に分けられる。セキュリティリリースの頻度が増えると、時折ある計画されたリリースは、番号を付け直す必要があることを意味する。このことがOracleに問題を引き起こす原因になる。なぜなら、それは、修正や機能強化をバグ追跡システムにおける特定のリリースに割り当てる事ができない、ことを意味するからである。
これを回避するためにOracle が決めたのは、
- Limited Update リリースは、20の倍数に番号付けされる。
- 我々は、Critical Patch Updates には引き続き奇数番号を使うつもりである。番号は、５の倍数をその前のLimited Update に加えて計算する。結果が奇数となるように必要であれば１を加える
例を使って非常に良く説明されている。
次のJDK 7用 Limited Updateが7u40と番号付けされている。その後の次の 3 CPUは、7u45, 7u51, 7u55と番号付けされる。その次の Limited Update は、7u60で、CPUは、7u65, 7u71, 7u75となる。この番号付け方法では、リリース間に幾つかの番号の余地があるので、リリースを挿入できる。 – 例えば、セキュリティ警告やサポートリリースが必要になった場合、後のリリースの番号を付け直す必要がない。
Sun/Oracleで１２年間に渡ってJavaクライアントサイドのエンジニアである、Oracleの Phil Race氏は、自分がこの議論に関わっていない、と言いながら、OpenJDKのメーリングリストにもっと詳しい情報を提供している。
セキュリティ用のアップデートリリースが奇数で、他のリリースが偶数、というのが慣例になりました。このことが外部でどのくらい重要かは、わかりませんが、２つのセキュリティリリースが間にリリースを挟まずに起きた場合、この慣例を破るべきか决定する必要があります。
我々には、２，３の計画外のリリースを行う必要性から多くの混乱が引き起こされていました。 7u14のビルドが存在し、そのリリースでバグが修正されたと記され、レポート、ステータスなどすべてがそのリリースを参照しました。しかしそのデータ全てが間違いとなり、その作業は、（願わくば）7u40で始めて陽の目を見ることになります。それまでは、内部の人も外部の人も、なぜ7u14で修正されたはずのバグが7u17でまた再現するのか理解できないでしょう。なので、セキュリティ以外のリリース番号の間に非常に余裕のある隙間を残すのは、我々が急いで番号の付け直しをする必要がない、ということです。
計画されたセキュリティのリリース番号の間に隙間を残すのは、どんな計画されていないリリースが起きた場合、既にとってある場所がある、ということです。セキュリティリリースに奇数を使い続ける慣例は、もっと数字を使うことになります。そのために、このような不可解なジャンプのある番号になってしまうわけです。
例 :
7u15 は、計画されたセキュリティリリース
7u17 は、計画されていなかったが予約された番号を使う（、と思う）
7u19 は、念の為に予約されたが、必要でなかった
7u21 は、計画されたセキュリティリリース
など...
Oracleが言うには、もっとエレガントな解決策は、異なる種類の変更に対応するためにバージョン番号付のスキームを変更する必要がある（例えば、7u44-2を使って）。しかし、これをメジャーリリース外で実装することはできない。もし、そうしたらバージョン文字列をパースする既存のコードが破綻してしまい（おそらくJavaの自動アップデートシステムも）、会社名がSun Microsystems から Oracleに変わった時に起きたことを漠然と思い出させるようなことになるだろう。更に、このような変更が非常に遅れている Java 8 のリリースの時に起きる可能性は、無いだろう。