Oracle调整Java SE版本编号方案

“为避免版本重新编号而引起的混乱”，Oracle已经宣布JDK 5.0、JDK 6和JDK 7将采用新的编号方案。Java子版本分为计划内Limited Update版本和Critical Patch Updates（CPUs），Limited Update版本包含非安全相关的缺陷修复和不定期的新功能增加，CPU版本则包含安全漏洞的修复。安全版本的发布频率增加意味着计划内版本会不定期的调整编号。这给Oracle带来了问题——这意味着在缺陷跟踪系统中，缺陷修复和功能增强无法分派到特定的版本上。

为解决此问题，Oracle已经决定：

• 使用20的倍数作为Limited Update版本编号。
• 我们想继续使用奇数来为Critical Patch Updates编号。编号的计算方式为：前一版本的Limited Update编号加5的倍数，如果结果为偶数，则再加1。

下面举例说明：

JDK 7的下一个Limited Update将会编号为7u40，之后的3个CPU编号分别为7u45、7u51和7u55。之后的Limited Update版本编号则为7u60，CPU编号分别为7u65、7u71和7u75。

编号方案将在不同版本保留一些空间，这样我们可以加入一些版本，比如说一些必要的安全警告或支持性的版本，而无需将后续的版本重新编号。

Oracle的Phil Race，一位Java客户端团队的工程师，已经在Sun/Oracle工作12年以上，表示自己没有参与相关的讨论，但他在OpenJDK的邮件列表中提供了一些更详细的信息。

我们习惯使用奇数作为安全更新的版本编号，其他版本使用偶数。我不确定这对外界有多重要，但是如果你要打破常规，将有可能出现两个安全更新版本连号的问题。

一些计划外版本的需求也给我们带来一些困惑。版本7u14已经存在，版本中缺陷已经标记为修复，reports、stats、etc等都引用了这个版本，但因版本号的调整，现在这些引用数据都是错误的，（希望）这些工作将在7u40中重见天日。在此期间，不论内部还是外部人员都无法理解，为什么一个据称在7u14中修复的缺陷，又在7u17中重现了。所以，在非安全版本号之间留下充足的空间，就不用我们在工作中重新调整版本号了。

计划内安全版本号之间的空间是为计划外的版本预留的，为了以防万一。而为安全版本所保留奇数编号的习惯，将会用掉更多的编号。所以，令人高深莫测的编号跳跃问题今后将彻底终结。

比如：

7u15是计划内的安全发布
7u17是计划外的保留编号（个人看法）
7u19是为突发情况而保留的，不是必要的
7u21是计划内的安全发布

等等……

Oracle表示，在版本编号方案的调整上需要一种更加文艺的解决方案，以适应各类变化（比如说使用7u44-2这种方案）。然而，这种方案无法在主版本之外使用，因为这么做有可能使现有用于解析版本字符串的代码失效（可能还包括Java自动更新系统），某种程度上这还会让人回想起当公司名称由Sun Microsystems改名为Oracle时发生的事情。此外，因为Java 8的延迟发布，Oracle不太可能及时作出这种改变。

查看英文原文：Oracle to Change the Release Numbering for Java SE