【按：本文分享自infoq中文网】

概述

9月21日Oracle发布了Java 9.0版本，同时Oracle宣布在9.0之后，会将Java的发布周期调整为每半年一次版本。

针对这种变化，Java平台组首席架构师Mark Reinhold在其个人博客中阐述了他的观点。

在过去的二十年间，Java SE平台和JDK经历了很大的变化，其中每个演变步骤都变更很大、不规则并且在一定程度上来讲很难预测。历史上，每个特性释放版本都是由一个或多个重要特性驱动的，所以为了适应这些特性的研发进度，发布日程也会按需进行调整，有时候甚至不止调整一次。

这样做的好处就是能够以非常高的质量交付大型的新特性，在这个过程中会经过早期采用者的全面审查和测试。但是，它所带来的不足就是小型的API、语言和平台的变更无法单独发布，只能等到大特性就绪之后才能交付。

在过去的二十年中，这种发布节奏还是可以的，因为当时与Java竞争的只有几个平台，基本都是采用类似的发布节奏。但是，现在Java要与很多的平台竞争，这些平台的演化节奏更快。Java为了保持竞争力，必须要不断前进，而且要前进地更快。

“列车”模式的版本发布

五年前，Mark Reinhold就曾经讨论过开发人员与企业之间不同的诉求，开发人员希望更快的革新，而企业更关注稳定性，但是每个人都希望规律且可预测的发布周期。

为了解决这个问题，当时Reinhold提出了将特性驱动的发布模式改为时间驱动的“列车”模式。在这种模式下，开发进程是一个持续的革新过程，它与实际的发布进程是松耦合的。不管特性大小，只有在接近完成的时候才合并进来。如果某个特性非常遗憾地错过了当前的这趟“列车”，那么这也不是世界末日，因为下一趟“列车”已经在等待中并且会按照时间表发车。

两年为间隔的“列车”模式在理论上很吸引人，但是事实证明在实践中行不通。Java 8为了解决关键的安全问题和完成Lambda项目多耗费了八个月的时间，但是这要比让Lambda项目再等两年更好一些。为了包含Jigsaw项目，Java 9最初的发布周期是两年半，虽然超出了半年，但是这要比让Jigsaw项目多等18个月更好，不过最终Java 9多耗费了一年的时间，也就是会在本月发布，这样从Java 8发布到现在经历了三年半的时间。

Reinhold认为，现在来看两年的发布周期太长了，交付特性的节奏应该更快一些。将某项特性推迟到下个版本发布，不应该是有重大影响的战略决策，而应该是影响不太大的战术性决策。因此，Reinhold认为六个月是一个合适的发布周期。它比以前更快，会减少等待下一趟“列车”的痛苦，同时也有足够的时间保证每次发布的质量。

提议

根据其他平台和各种操作系统版本的发布模式，Reinhold建议在Java 9之后，采用一种更严格基于时间模式，每六个月发布一个新特性释放版本，每季度发布一个更新释放版本，每三年发布一个长期支持的发布版本。

• 特性发布版本可以包含任何类型的特性，不仅包括新的以及增强的API，还包含语言和JVM的特性。特性只有在接近完成的时候，才会合并进来，所以当前要释放的版本始终都是特性已完成的状态。特性发布版本会在每年的三月和九月交付，从2018年的三月开始。

• 更新释放版本会被严格限制，只能解决安全问题、回归测试中的问题和bug。每个特性发布版本都会有两个更新版本，更新版本会按照季度发布，在每年的一月、四月、七月和十月交付。

• 从2018年的九月开始，特性发布版本同时也会是一个长期支持版本。对这些发布版本，至少会支持三年，甚至更长时间。

每半年交付一次的发布版本会比多年才交付一次的版本体量更小，更易于采用，同时为旧释放版本打补丁也会更容易。

开发人员更喜欢快节奏的创新，那么他们可以使用最新的特性发布版本或特性更新版本，这样就能尽快在生产环境使用新特性。他们可以通过Docker镜像或其他类型的容器包交付应用，容器中会同时包含应用所要使用的Java发布版本。

企业会更加关注稳定性，那么可以让多个大型的应用使用相同的Java版本，他们可以使用长期支持的发布版。像常规工作一样，他们可以每三年规划一次长期维护版本的升级。

为了明确特定版本的发布时间，特性发布版的版本号格式为$YEAR.$MONTH，因此明年三月份的发布版将会是18.3，九月份的长期维护版将会是18.9。

Reinhold认为，如果采用这种模式的话，将会影响到OpenJDK社区的贡献者。这项提议会最终影响每个依赖Java的开发者、用户和企业。但是，如果成功的话，将会在未来的很多年内保持Java的竞争力，同时能维持它的核心价值，也就是兼容性、可靠性以及稳健的特性演化。