最近發布的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