Spring改變版本號命名規則：此舉對非英語國家很友好

要想改變命運，首先改變自己。本文已被 https://www.yourbatman.cn 收錄，裡面一併有Spring技術棧、MyBatis、JVM、中介軟體等小而美的專欄供以免費學習。關注公眾號【BAT的烏托邦】逐個擊破，深入掌握，拒絕淺嘗輒止。

目錄

• ✍前言
• ✍正文
  • Release Train
    • 為何需要Release Train發版模式？
  • Project Module
  • Semantic Versioning
    • 版本號組成
    • 版本號比較
  • Calendar Versioning
    • 方案類別
  • Spring改變版本號命名規則
    • Release Train版本規則改變
      • 存在的問題
      • 解決問題（改變後）
    • Project Module版本規則改變
• ✍總結
  • ✔推薦閱讀：

✍前言

你好，我是YourBatman。

還記得在今年5月份樣子看到了一篇來自Pivotal的郵件，大致內容是說Spring改變了版本號的命名規則，當時本著先收藏一下準備晚上再看，然後，就沒有然後了。

直到前些天突然看到了篇標題為：Spring Data 2020.0.0正式釋出的文章，這才讓我把此事聯想了起來，因此才決定寫此文記錄一下，順帶分享給你。

若你已苦於Spring Cloud的版本號命名方式，那麼本文給你帶來了曙光

✍正文

天下苦Spring Cloud版本命名久矣。在正式開始之前，管生管養的A哥有意對這其中的相關名詞進行解釋，方便理解本文。

Release Train

Release Train直譯過來意思為：發版火車/火車發版。火車大家不陌生，它有一個顯著的特點：定時定點發車。這裡的發車在軟體領域就等同於軟體的發版。

為何需要Release Train發版模式？

在公司還很小很小的時候，整個公司可能只有一個軟體，版本釋出非常的簡單，沒什麼需要協調的，發就完了。但是，一旦公司快速發展變得比較大後，核心產品功能數以十、百計，各功能模組由不同的團隊負責，溝通成本明顯升高，單單在版本上稍不注意就會產生各種問題，很容易給人一種“亂如麻”的感覺。

使用Release Train的發版模式就能很大程度上避免這些問題，可以這樣做：規定每個月的最後一天（精確的發版日期）需要發一版（類比於火車發車），那麼就可以以這個時間點為deadline，參與的的各方包括產品經理、RD、QA等等都提前溝通好需求內容，並做好計劃，充分做好統一發車的準備。在這期間，如果中間某一團隊出現問題跟不上節奏了，那麼請及時下車（前提是控制好下車的影響面），不要影響整體發車時間點。

總的來講：火車是按點準時出發的，各方應按點上車，倘若本次趕不上車的那麼就請等下一趟車。通過這種方式可以確保軟體產品的持續迭代，保證產品的穩定性，這就是Release Train發版模式。

在實際的軟體產品中，可以認為稍微大一點的軟體都是按照此模式來持續迭代的，比如IOS、maxOS、MIUI、Spring Cloud等等。這些軟體版本在命名方式上不同但均遵循一定規律：

• IOS 14、IOS 14.1、IOS14.1.1
• macOS Mojave、macOS Sierra
• Spring Cloud Greenwich、Spring Cloud Hoxton

Project Module

如果說按照Release Train發版模式發出的一個版本代表著一個大的產品版本號，那麼Project Module就代表其內部的模組。一般一個軟體產品由N多個模組組成，以最新的Spring Data 2020.0.0版本為例，內含有多個Project Module模組：

• Spring Data Commons 2.4
• Spring Data JDBC 2.1
• Spring Data JPA 2.4
• Spring Data MongoDB 3.1
• Spring Data KeyValue 2.4
• Spring Data LDAP 2.4
• Spring Data Elasticsearch 4.1
• ...

Semantic Versioning

語義化版本號，有被稱作語義化版本控制規範，簡稱“SemVer”。它是一套版本號規則的標準/規範，用於改善軟體版本號格式混亂問題，順便統一一下版本號所表達的含義。官方主頁是：https://semver.org

版本號組成

SemVer版本號主要由三個部分組成，每個部分是一個非負整數，部分和部分之間用.分隔：主版本號.次版本號.修訂號（簡寫為x.y.z）。下面對這三部分做出解釋（約定）：

• 主版本號：只有進行非向下相容的修改或者顛覆性的更新時，主版本號加1
  • 話外音：改變很大，暴力式更改
• 次版本號：進行向下相容的修改或者新增相容性的新功能時，次版本號加1
  • 話外音：改變不很大，一般是向下相容的。值得注意的是：這裡指的是一般，有些情況也存在不相容情況也是允許的，當然不能是主要功能不相容
• 補丁號：沒有新功能加入，一般修復bug、優化程式碼等，補丁號加1
  • 話外音：此版本號可放心無縫升級

關於這三部分還有兩點值得注意：

1. 版本號均從0開始（包括主版本號）
   1. 主版本號為零（0.y.z）的軟體處於開發初始階段，一切都可能隨時被改變。這樣的公共 API 不應該被視為穩定版
   2. 1.0.0 的版本號用於界定公共 API 的形成。也就說從
2. 當主版本號更新時，次版本號和補丁號都要歸零；次版本號更新時補丁號歸零

版本號比較

這種三段式的版本號是可以比較大小的。比較的順序是：主版本號、次版本號、補丁號。舉例：4.3.0 < 5.0.0 < 5.0.3 < 5.1.0

說明：使用.分隔開的話，正常比較（當字串比較）是不會出現形如.2. > .10.的問題的

值得注意的是，Semantic Versioning只是一個標準，它並沒有提供實現（比如版本號比較），雖然按照此規則自己實現一個並不複雜，但我建議各位不要自己實現，畢竟這種輪子社群裡大把的，各種語言的都有哦，何必重複造呢。

Calendar Versioning

日曆化版本，簡稱CalVer。CalVer不是基於任意數字，而是基於專案釋出日期的版本控制約定。相較於語義化版本號，日曆化版本號更接地氣，顯得活力更強些。因為日期是單向向前的，因此版本隨著時間的推移會變得更好。

方案類別

有多種日曆化版本方案，長期被各種大小專案使用。對於CalVer來說，它的規範非常抽象，畢竟釋出日期本就是一個很抽象的概念嘛。

CalVer 並未像 “語義化版本” 那樣選擇單一方案， 而是引入了開發人員的 標準術語：

• YYYY：年份全稱。如：2020
• YY：年費縮寫。如：20
• MM：月份縮寫。如：1、2、3
• DD：日縮寫。如：1、2、3
• ...

和日期格式化類似有木有。是的，日期你可以隨意，甚至可以是任意遞增格式，但建議使用標準格式而已。

Spring改變版本號命名規則

Spring團隊在其官網部落格裡於2020-04-30對外宣佈要改變版本號命名規則，共包含兩部分的內容：

1. Release Train版本規則改變
2. Project Module版本規則改變

這些改變將在下一個釋出版本里體現出來，比如我們已經能看到的使用新規則命名版本號的是：Spring Data 2020.0.0、Spring Data 2020.0.1

Release Train版本規則改變

Spring自2013年以來一直按照字母表順序來進行排序版本。舉例兩個典型的，也是我們比較熟悉的按照Release Train發版的專案給你瞧一瞧，我繪製成圖示如下：

Spring Data：

Release Train	釋出日期
Spring Data Arora	2013-02
Spring Data Babbage	2013-09
Spring Data Codd	2014-02
Spring Data Dijkstra	2014-05
...	...
Spring Data Neumann	2020-05
Spring Data 2020.0.0	2020-10

Spring Cloud：

Release Train	釋出日期
Spring Cloud Angel	2015-06
Spring Cloud Brixton	2016-05
Spring Cloud Camden	2016-09
Spring Cloud Dalston	2017-04
...	...
Spring Cloud Hoxton	2019-11
Spring Cloud 2020.0.0-M4	2020-10

注意：截止目前，Spring Cloud 2020的正式版還未正式釋出，預計11月結束之前會正式推出，以支援Spring Boot 2.4.0

存在的問題

如上表所示，按照字母表排序作為版本號是存在如下問題的：

1. 按照字母排序，對於非英文國家有一定門檻難以記憶（比如天朝的程式設計師們）
2. 如果排序字母到達Z了，就會出現命名上的難題了
3. 從版本號上不能體現出向下相容性，著讓使用者（準備升級者）很難做出判斷而做出風險預估
4. 單詞的拼寫很困難（版本號都得靠複製，現在是降低效率的表現）

解決問題（改變後）

為了解決這些問題，Spring採用了日曆化版本，並且使用的規則/公式是YYYY.MINOR.MICRO[-MODIFIER]，對各部分解釋如下：

• YYYY：年份全稱。eg：2020
• MINOR：輔助版本號（一般升級些非主線功能），在當前年內從0遞增
• MICRO：補丁版本號（一般修復些bug），在當前年內從0遞增
• MODIFIER：非必填。字尾，它用於修飾一些關鍵節點，用這些字母表示
  • M數字：里程碑版本，如2020.0.0-M1、2020.0.0-M2
  • RC數字：釋出候選版本，如2020.0.0-RC1、2020.0.0-RC2
  • SNAPSHOT：快照版本（後無數字哦），如2020.0.0-SNAPSHOT
  • 啥都木有：正式版本（可放心使用，相當於之前的xxx-RELEASE），如2020.0.0

通過新的版本命名方式，解決了向後相容帶來的問題（一看版本號就能清晰的知道向後相容性如何），不再存在上限焦慮了，並且這種排序對非英語國家非常友好，點贊。

自此，對於Spring Cloud來說H版是它最後一個用英文單詞命名的版本號了，下個版本將是Spring Cloud 2020.0.0，預計在本月正式釋出。

Project Module版本規則改變

對於專案模組的版本號而言，其實Spring早在其3.0.0.M1版本（2008年）就使用了“語義化版本”規則進行釋出管理。本可以不用做改動也行，但Spring官方覺得既然這次對Release Train做了修整，那就一起調整下是更好的。

專案模組的版本規則Spirng採用Semantic Versioning語義版本號規範，另外呢Spring還希望開發者很容易熟悉這個版本號，因此制定了這個模版：MAJOR.MINOR.PATCH[-MODIFIER]。前面三部分就不再解釋啦，詳情請看上面的關於Semantic Versioning的說明。對於最後面的MODIFIER部分保持了和Release Train一模一樣的語義：

• MODIFIER：非必填。字尾，它用於修飾一些關鍵節點，用這些字母表示
  • M數字：里程碑版本，如2.4.0-M1、2.4.0-M2
  • RC數字：釋出候選版本，如2.4.0-RC1、2.4.0-RC2
  • SNAPSHOT：快照版本（後無數字哦），如2.4.0-SNAPSHOT
  • 啥都木有：正式版本（可放心使用，相當於之前的xxx-RELEASE），如2.4.0

總的來說此部分規則改變並不大，簡單對比就是這樣：

改變前	改變後
3.0.0.M1	3.0.0-M1

以最新發布的Spirng Framework版本為例，它應用了最新的發版規則：

<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-core</artifactId>
    <version>5.3.0</version>
    <!-- 5.2.0.RELEASE -->
</dependency>

對比新舊版本號可知，新規則最大的區別是幹掉了 .RELEASE，因此書寫時請稍加註意。

✍總結

本次Spring做出版本號規則的調整，更加彰顯活力。喜聞樂見的是這名稱對於處於天朝的我們是利好啊，畢竟SC的那些英文單詞你能記住幾個？現在書寫其版本號終於可以盲寫了，並且通過版本號能非常直觀的知曉到當前使用版本的新舊程度，從而做出相關判斷/預估，非常便捷。

另外，截止稿前，Spring Boot 2.4.0（注意木有.RELEASE了哦）以及Spring Framework 5.3.0均已重磅釋出，為了給馬上到來的Spring Cloud 2020.0.0做好鋪墊，接下來幾篇文章將對它倆進行闡述，歡迎持續關注。

✔推薦閱讀：

• JDK15正式釋出，劃時代的ZGC同時宣佈轉正
• IntelliJ IDEA 2020.2正式釋出，諸多亮點總有幾款能助你提效
• Spring Boot 2.3.0正式釋出：優雅停機、配置檔案位置萬用字元新特性一覽
• 搞事情？Spring Boot今天一口氣釋出三個版本