要想改變命運，首先改變自己。本文已被 https://www.yourbatman.cn 收錄，裡面一并有Spring技術棧、MyBatis、JVM、中間件等小而美的專欄供以免費學習。關注公衆号【BAT的烏托邦】逐個擊破，深入掌握，拒絕淺嘗辄止。
✍前言
你好，我是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
- 話外音：此版本号可放心無縫更新
關于這三部分還有兩點值得注意：
- 版本号均從0開始（包括主版本号）
- 主版本号為零（0.y.z）的軟體處于開發初始階段，一切都可能随時被改變。這樣的公共 API 不應該被視為穩定版
- 1.0.0 的版本号用于界定公共 API 的形成。也就說從
- 當主版本号更新時，次版本号和更新檔号都要歸零；次版本号更新時更新檔号歸零
版本号比較
這種三段式的版本号是可以比較大小的。比較的順序是：主版本号、次版本号、更新檔号。舉例：
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對外宣布要改變版本号命名規則，共包含兩部分的内容：
- Release Train版本規則改變
- Project Module版本規則改變
這些改變将在下一個釋出版本裡展現出來，比如我們已經能看到的使用新規則命名版本号的是：Spring Data 2020.0.0、Spring Data 2020.0.1
Spring自2013年以來一直按照字母表順序來進行排序版本。舉例兩個典型的，也是我們比較熟悉的按照Release Train發版的項目給你瞧一瞧，我繪制成圖示如下：
Spring Data：
| 釋出日期 | |
|---|---|
| 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 Cloud：
| 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的正式版還未正式釋出，預計11月結束之前會正式推出，以支援Spring Boot 2.4.0
存在的問題
如上表所示，按照字母表排序作為版本号是存在如下問題的：
- 按照字母排序，對于非英文國家有一定門檻難以記憶（比如天朝的程式員們）
- 如果排序字母到達
Z
- 從版本号上不能展現出向下相容性，着讓使用者（準備更新者）很難做出判斷而做出風險預估
- 單詞的拼寫很困難（版本号都得靠複制，現在是降低效率的表現）
解決問題（改變後）
為了解決這些問題，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
，預計在本月正式釋出。
對于項目子產品的版本号而言，其實Spring早在其
3.0.0.M1
版本（2008年）就使用了“語義化版本”規則進行釋出管理。本可以不用做改動也行，但Spring官方覺得既然這次對Release Train做了修整，那就一起調整下是更好的。
項目子產品的版本規則Spirng采用Semantic Versioning語義版本号規範，另外呢Spring還希望開發者很容易熟悉這個版本号，是以制定了這個模版：
MAJOR.MINOR.PATCH[-MODIFIER]
。前面三部分就不再解釋啦，詳情請看上面的關于
Semantic Versioning
的說明。對于最後面的MODIFIER部分保持了和Release Train一模一樣的語義：
-
- M數字：裡程碑版本，如2.4.0-M1、2.4.0-M2
- RC數字：釋出候選版本，如2.4.0-RC1、2.4.0-RC2
- SNAPSHOT：快照版本（後無數字哦），如2.4.0-SNAPSHOT
-
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做好鋪墊，接下來幾篇文章将對它倆進行闡述，歡迎持續關注。