最近发布的 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 月份发布。该提议仍然处于讨论之中，不过很快就会有一个结果。
评论