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