> 要想改變命運，首先改變自己。本文已被 [**https://www.yourbatman.cn**](https://www.yourbatman.cn) 收錄，裡面一併有Spring技術棧、MyBatis、JVM、中介軟體等小而美的**專欄**供以免費學習。關注公眾號【**BAT的烏托邦**】逐個擊破，深入掌握，拒絕淺嘗輒止。 [TOC]  # ✍前言 你好，我是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](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版本為例，它應用了最新的發版規則： ```xml org.springframework

spring-core 5.3.0 ``` 對比新舊版本號可知，新規則最大的區別是**幹掉了** `.RELEASE`，因此書寫時請稍加註意。 # ✍總結 本次Spring做出版本號規則的調整，更加彰顯活力。喜聞樂見的是這名稱對於處於天朝的我們是利好啊，畢竟SC的那些英文單詞你能記住幾個？現在書寫其版本號終於可以**盲寫**了，並且通過版本號能**非常直觀**的知曉到當前使用版本的新舊程度，從而做出相關判斷/預估，非常便捷。 另外，截止稿前，Spring Boot 2.4.0（注意木有.RELEASE了哦）以及Spring Framework 5.3.0均已重磅釋出，為了給馬上到來的Spring Cloud 2020.0.0做好鋪墊，接下來幾篇文章將對它倆進行闡述，歡迎持續關注。 ##### ✔推薦閱讀： - [JDK15正式釋出，劃時代的ZGC同時宣佈轉正](https://mp.weixin.qq.com/s/3QaiUGzj5nW2N4Aipm47PQ) - [IntelliJ IDEA 2020.2正式釋出，諸多亮點總有幾款能助你提效](https://mp.weixin.qq.com/s/8voJSbmcBbdfNUCUBIcKcA) - [Spring Boot 2.3.0正式釋出：優雅停機、配置檔案位置萬用字元新特性一覽](https://mp.weixin.qq.com/s/ikI9c3XyR_czOSmsu6FLMw) - [搞事情？Spring Boot今天一口氣釋出三個版本](https://mp.weixin.qq.com/s/nb4oT02dlU4pxINZw9aLLw)