“为避免版本重新编号而引起的混乱”，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 不太可能及时作出这种改变。
评论