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

要想改變命運，首先改變本身。本文已被 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發版模式？

在公司還很小很小的時候，整個公司可能只有一個軟件，版本發佈很是的簡單，沒什麼須要協調的，發就完了。可是，一旦公司快速發展變得比較大後，核心產品功能數以10、百計，各功能模塊由不一樣的團隊負責，溝通成本明顯升高，單單在版本上稍不注意就會產生各類問題，很容易給人一種「亂如麻」的感受。

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

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

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

• IOS 1四、IOS 14.一、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」。它是一套版本號規則的標準/規範，用於改善軟件版本號格式混亂問題，順便統一一下版本號所表達的含義。官方主頁是：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：月份縮寫。如：一、二、3
• DD：日縮寫。如：一、二、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-M一、2020.0.0-M2
  • RC數字：發佈候選版本，如2020.0.0-RC一、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-M一、2.4.0-M2
  • RC數字：發佈候選版本，如2.4.0-RC一、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今天一口氣發佈三個版本