最新的Java SE平臺和JDK版本釋出計劃

最近釋出的Java 9帶來了諸多重大變更，包括一個全新的版本釋出計劃。該釋出計劃基於JEP 223，主要用於Java平臺未來的版本釋出。

\\

不過在新版本計劃釋出之後，Java首席架構師Mark Reinhold立即提議再次修改當前的版本計劃，使用更為嚴格的基於時間的釋出模型。

\\

基於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在jdk-dev郵件組中為基於絕對時間的版本模型做出辯護：

\\

\

• \\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月份釋出。該提議仍然處於討論之中，不過很快就會有一個結果。

\\

檢視英文原文：New Version Scheme for Java SE Platform and the JDK

\\