最新的 Java SE 平台和 JDK 版本发布计划

最近发布的 Java 9 带来了诸多重大变更，包括一个全新的版本发布计划。该发布计划基于 JEP 223 ，主要用于 Java 平台未来的版本发布。

不过在新版本计划发布之后，Java 首席架构师 Mark Reinhold 立即提议再次修改当前的版本计划，使用更为严格的基于时间的发布模型。

基于 JEP 223 的版本计划主要目标如下：

• 版本号更易于理解
• 与当前业界的实际情况相吻合
• 能够适用于已有的包系统和平台部署机制
• 避免在版本号中使用两种信息元素
• 提供简单的 API 用于解析、验证和比较版本号

Java 9 的发布说明对新的版本号格式进行了描述：

 
$MAJOR.$MINOR.$SECURITY.$PATCH

• $MAJOR版本号随着主要版本的发布而增加，发布版本中需要包含实现了 Java SE 平台规范的重要新特性。主要版本中包含的新特性会提前进行计划和声明。
• $MINOR版本号随着次要版本的发布而增加，比如缺陷修复、修订标准 API 或者实现了平台规范以外的特性。
• $SECURITY版本号随着安全更新的发布而增加，发布版本中需要包含关键的安全问题修复。
• $PATCH版本号随着包含了安全和高优先级用户问题修复的版本发布而增加。

Reinhold 提议使用一种基于时间的发布模型来代替该发布计划。他说，Java SE 平台在过去几年经历了非同寻常的变化。

基于特性发布的方式一般都是因为需要与特性的开发速度保持一致。Reinhold 说，这种发布方式已经过时了，Java 现在需要与那些发展迅速的平台展开竞争。

受其他平台和各种操作系统发行计划的启发，我提议在 Java 9 之后使用一种严格的基于时间的发布模型，每六个月进行一次特性发布，每季度进行一次更新发布，每三年进行一次 LTS（长期支持）发布。

该模型可以让那些急于尝鲜的开发者快速地采用最新的特性，而追求稳定性的企业则可以选择长期支持版本。他们可以提前进行计划，从一个长期支持版本迁移到下一个长期支持版本。

被提议的版本号格式如下：

 
$YEAR.$MONTH

也就是说，2018 年 3 月份的版本将会是 18.3，2018 年 9 月份的版本为 18.9。Reinhold 在 jdk-dev 邮件组中为基于绝对时间的版本模型做出辩护：

• 绝对时间恰好反应出了发布日期，因为是基于时间的，所以对 JDK 的开发者和用户来说一目了然。如果因为要额外“新增一个特性”导致发布延迟也不会引起混乱。
• 根据绝对时间可以很容易地知道版本有多旧，所以用户就可以知道自己使用的版本有多落后。而如果是相对时间，则需要知道时间单位是什么，以及版本号是基于什么时间计算得出的。
• 绝对时间与发布节奏相互独立。如果在若干年后，我们采用更快的发布节奏，比如三个月，就不需要修改绝对时间，但如果是相对时间则需要调整时间单位和起点。

基于绝对时间的版本模型在社区中还不是很流行，Reinhold 在邮件组中提出了修订版本。修订版与最初在 JEP 223 中出现的版本类似，只是做出了折中。

最新提议的版本号格式如下：

 
$FEATURE.$INTERIM.$UPDATE.$EMERG

• $FEATURE计数每六个月增加一次，不管发布的内容是什么。
• $INTERIM计数的增加并不包含特性发布，而是缺陷修复和增强，不包含不兼容的变更。对于当前的六个月周期发布模型来说，这个数字一般是零。
• $UPDATE计数每三个月增加一次，包含兼容性的更新，如安全问题修复、回退问题修复以及新特性问题修复。
• $EMERG计数只在需要发布紧急版本的时候增加。

基本上这也是一种基于时间的发布计划。$FEATURE 每六个月增加一次，$UPDATE 每三个月增加一次。

如果使用这种模型，下一个特性发布版本（之前叫作主要版本）仍然是 Java 10，将于 2018 年 3 月份发布，而 Java 11 将于 2018 年 9 月份发布。该提议仍然处于讨论之中，不过很快就会有一个结果。

查看英文原文： New Version Scheme for Java SE Platform and the JDK