Spring 團隊決定更改釋出火車和專案模組的版本控制方案。這些更改將在下一個釋出火車和每個專案的次要版本中實現。事實上，這些更改已經出現在 Spring Cloud 2020.0.0-M1 中。Maven 和 Gradle 不提供完全相同的版本排序，但我們正在與 Gradle 團隊合作，以確保 Spring 方案在這兩種工具中都能以相同的方式排序。

釋出火車版本更改

自 2013 年以來，Spring 一直使用按字母順序排列的、主題化的釋出火車版本。釋出火車包含一組協同工作的專案版本，但升級到下一個釋出火車時，不保證底層庫的向後相容性。

從那時起，社群對版本名稱提出了一些擔憂，我們聽取了意見。一個主要擔憂是該方案對於非英語母語者按字母順序排序可能具有挑戰性。此外，主題名稱可能難以記住版本名稱。最後，一些主題名稱可能難以拼寫。

為了解決這些問題，Spring 團隊決定切換到日曆版本控制 (calver)，使用 YYYY.MINOR.MICRO[-MODIFIER] 的方案，其中：

• YYYY 是完整年份。

• MINOR 是每年遞增的、基於 0 的數字。

• MICRO 是補丁版本。

• MODIFIER 是一個可選修飾符，其中 <COUNT> 是一個遞增的基於 1 的數字

  • 對於里程碑，我們將使用 M<COUNT>。

  • 對於釋出候選版本，我們將使用 RC<COUNT>。

  • 對於快照，我們將使用 -SNAPSHOT。請注意，我們以前方案中存在的 .BUILD 已被刪除。

  • 對於釋出版本，將沒有修飾符。

按順序排列的版本示例將是 2020.0.0-M1、2020.0.0-M2、2020.0.0-RC1、2020.0.0-SNAPSHOT、2020.0.0、2020.0.1-SNAPSHOT、2020.0.1、2020.1.0-M1、2020.1.0-M2、2020.1.0-RC1、2020.1.0-SNAPSHOT、2020.1.0 等等。

這解決了對向後相容性影響的擔憂，簡化了非英語母語者的排序，比基於名稱的釋出更容易記住，並消除了拼寫挑戰。與許多其他使用 calver 的專案一樣，Spring 團隊也可能會繼續使用遵循舊版本約定代號來指代每個釋出火車。

專案模組版本更改

自 2008 年的 Spring Framework 3.0.0.M1 以來，Spring 團隊一直使用與 OSGi 語義版本控制相容的版本。我們覺得，既然我們正在重新審視釋出火車版本控制方案，那麼重新審視我們的專案模組版本也將是件好事。

雖然擁有 OSGi 相容版本很方便，但 Maven 版本不必與 OSGi 相容，因為捆綁包元資料可以在其中指定 OSGi 相容版本。我們決定新的版本控制方案將遵循 語義版本控制 中定義的語法，以幫助解析版本號。我們還希望我們的版本對 Java 開發人員來說是熟悉的。鑑於上述資訊，我們決定切換到 MAJOR.MINOR.PATCH[-MODIFIER] 的版本方案，其中：

• MAJOR，如果遞增，可能涉及大量的升級工作。

• MINOR，如果遞增，應該涉及很少或沒有升級工作。

• PATCH，如果遞增，應該不涉及任何工作。

• MODIFIER 是一個可選修飾符，其中 <COUNT> 是一個遞增的基於 1 的數字

  • 對於里程碑，我們將使用 M<COUNT>。

  • 對於釋出候選版本，我們將使用 RC<COUNT>。

  • 對於快照，我們將使用 -SNAPSHOT。請注意，我們以前方案中存在的 .BUILD 已被刪除。

  • 對於釋出版本，將沒有修飾符。

按順序排列的版本示例將是 2.3.0-M1、2.3.0-M2、2.3.0-RC1、2.3.0-RC2、2.3.0-SNAPSHOT、2.3.0、2.3.1-SNAPSHOT、2.3.1、2.4.0-M1、2.4.0-M2、2.4.0-RC1、2.4.0-SNAPSHOT、2.4.0 等等。

結論

我們衷心感謝社群的反饋，希望這些更改能改善您使用 Spring 的體驗！