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

釋出列車版本變更

Spring 自 2013 年以來一直使用按字母順序排列、帶有主題的釋出列車版本。釋出列車包含一組配合良好的專案版本，但在升級到下一個釋出列車時，不保證底層庫的向後相容性。

從那時起，社群對版本名稱提出了一些擔憂，我們也聽取了意見。主要擔憂是，對於非英語母語者來說，按字母順序排序這個方案可能會比較困難。此外，帶有主題的名稱可能難以記住版本名稱。最後，一些主題名稱可能難以拼寫。

為了解決這些擔憂，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 Semantic Versioning 相容的版本。我們認為，既然我們正在重新審視釋出列車的版本方案，那麼也應該重新審視專案模組的版本。

雖然擁有 OSGi 相容版本很方便，但 Maven 版本並不需要這樣做也能與 OSGi 相容，因為 bundle 元資料可以在其中指定一個 OSGi 相容的版本。我們決定新的版本方案將遵循語義版本控制 (Semantic Versioning) 中定義的語法，以幫助解析版本號。我們也希望我們的版本能讓 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 的體驗！