語義化版本控制規範

語義化版本控制規範

1、問題

若是沒有一個統一完善的語義化版本規範， 開發者安裝某個軟件包時，發現這個軟件包裏又依賴不一樣特定版本的其它軟件包。隨着系統功能愈來愈複雜，依賴的軟件包愈來愈多，依賴關係也愈來愈深，這個時候可能面臨版本控制被鎖死的風險，也就是出現「依賴地獄」 問題。

2、說明

語義化版本控制的規範是由 Gravatars 創辦者兼 GitHub 共同創辦者 Tom Preston-Werner 創建。
官網地址：https://semver.org/

規範的概要以下：
版本格式：主版本號.次版本號.修訂號

1. 主版本號： 功能性主導的規劃實現，非兼容性修改。
2. 次版本號： 向下兼容的功能性的新增與修改。
3. 修訂號：向下兼容的問題修正。
4. 修訂號：修復問題時使用，採用遞增方式。

3、語義化版本控制規範

1. 標準的版本號必須採用XYZ的格式，而且X、Y 和 Z 爲非負的整數，禁止在數字前方補零，版本發佈須要嚴格遞增。例如：1.9.1 -> 1.10.0 -> 1.11.0。
2. 某個版本正式發行後，禁止改變該版本的內容，任何修改都必須基於發佈的新版本。
3. 主版本號爲零（0.y.z）的軟件， 標識處於研發初始階段，一切均可能隨時發生變化或被改變。這樣的版本提供的公共 API 不該該被視爲穩定版。
4. 1.0.0 的版本號用於界定正式版本的造成。當軟件發佈到了正式環境，或者有穩定的API功能時，就能夠發佈1.0.0版本。
5. 次版本號 Y（x.Y.z | x > 0）必須在有向下兼容的新功能出現時遞增。也能夠在內部程序有大量新功能或改進被加入時遞增。每當次版本號遞增時，修訂號必須歸零。
6. 修訂號 Z（x.y.Z | x > 0）必須在只作了向下兼容的修正時才遞增。這裏的修正指的是針對不正確結果而進行的內部修改，好比線上的功能缺陷等。
7. 主版本號 X（X.y.z | X > 0）必須在有非兼容性的修改時遞增，好比出現新的功能需求。每當主版本號遞增時，次版本號和修訂號必須歸零。
8. 版本的優先層級指的是不一樣版本在排序時如何比較。判斷優先層級時，必須把版本依序拆分爲主版本號、次版本號、修訂號及先行版本號後進行比較。
9. 先行的版本號能夠被標註在修訂版以後，先加上一個鏈接號再加上一連串以句點分隔的標識符來修飾。標識符必須由 ASCII 字母數字和鏈接號 [0-9A-Za-z-] 組成，且禁止留白。先行版的優先級低於相關聯的標準版本。 被標上先行版本號則表示這個版本並不是穩定並且可能沒法知足預期的兼容性需求。例如：1.0.0-alpha、1.0.0-alpha.一、1.0.0-0.3.七、1.0.0-x.7.z.92
10. 版本的優先層級指的是不一樣版本在排序時如何比較。判斷優先層級時，必須把版本依序拆分爲主版本號、次版本號、修訂號及先行版本號後進行比較。由左到右依序比較每一個標識符，第一個差別值用來決定優先層級，主版本號、次版本號和修訂號以數值進行比較，例如：1.0.0 < 2.0.0 < 2.1.0 < 2.1.1。
    當主版本號、次版本號和修訂號都相同時，則以優先層級比較低的先行版本號決定。例如：1.0.0-alpha < 1.0.0。有相同主版本號、次版本號及修訂號的兩個先行版本號，其優先層級必須透過由左到右的每一個被句點分隔的標識符來比較，直到找到一個差別值後決定。數字的標識符以數值高低比較，有字母或鏈接號時則以 ASCII 的排序來比較。優先級判斷示例：1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0。

4、實際案例說明

咱們來看看目前最流行的前端框架之一的React最近5個月的版本發佈日誌：

從上圖能夠得出結論：
1.軟件的版本一般由三位組成，形如：X.Y.Z
2.版本是嚴格遞增的，此處是：16.2.0 -> 16.3.0 -> 16.3.1
3.在發佈重要版本時，能夠發佈alpha, rc等先行版本
4.alpha和rc等修飾版本的關鍵字後面能夠帶上次數和meta信息
React 發佈版本時作的至關到位，版本給人的感受很是清晰，也很嚴謹。這得益於 Semver(語義化版本) 規範的功勞。

下面是聽從了Semver規範的React依賴圖：

聽從了Semver規範的包依賴很是清晰，沒有出現循環依賴、依賴衝突等常見問題

---

本文由mirson創做分享，如需進一步交流，請加QQ羣：19310171或訪問www.softart.cn