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

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

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

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

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

\$MAJOR.$MINOR.$SECURITY.$PATCH

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

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

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

\

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

\

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

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

\$YEAR.$MONTH

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

\

• \\t

  绝对时间恰好反应出了发布日期，因为是基于时间的，所以对JDK的开发者和用户来说一目了然。如果因为要额外“新增一个特性”导致发布延迟也不会引起混乱。

  \\t\\t
• \\t

  根据绝对时间可以很容易地知道版本有多旧，所以用户就可以知道自己使用的版本有多落后。而如果是相对时间，则需要知道时间单位是什么，以及版本号是基于什么时间计算得出的。

  \\t\\t
• \\t

  绝对时间与发布节奏相互独立。如果在若干年后，我们采用更快的发布节奏，比如三个月，就不需要修改绝对时间，但如果是相对时间则需要调整时间单位和起点。

  \\t\

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

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

\$FEATURE.$INTERIM.$UPDATE.$EMERG

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

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

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

查看英文原文：