首先看看某些常見軟體的版本號：
從上可以看出，不同的軟體版本號風格各異，隨著系統的規模越大，依賴的軟體越多，如果這些軟體沒有遵循一套規範的命名風格，容易造成 dependency hell。所以當我們發布版本時，版本號的命名需要遵循某種規則，其中 semantic versioning 2.0.0 定義了一套簡單的規則及條件來約束版本號的配置和增長。本文根據 semantic versionning 2.0.0 和 semantic versioning 3.0.0 選擇性的整理出版本號命名規則指南。
版本號命名規則指南
版本號的格式為 x.y.z(又稱 major.minor.patch)，遞增的規則為：
詳細的規則如下：
x, y, z 必須為非負整數，且不得包含前導零，必須按數值遞增，如 1.9.0 -> 1.10.0 -> 1.11.0
0.y.z 的版本號表明軟體處於初始開發階段，意味著 api 可能不穩定；1.0.0 表明版本已有穩定的 api。
當 api 的相容性變化時，x 必須遞增，y 和 z 同時設定為 0；當新增功能(不影響 api 的相容性)或者 api 被標記為 deprecated 時，y 必須遞增，同時 z 設定為 0；當進行 bug fix 時，z 必須遞增。
先行版本號(pre-release)意味該版本不穩定，可能存在相容性問題，其格式為：x.y.z.[a-c][正整數]，如 1.0.0.a1，1.0.0.b99，1.0.0.c1000。
開發版本號常用於 ci-cd，格式為 x.y.z.dev[正整數]，如 1.0.1.dev4。
版本號的排序規則為依次比較主版本號、次版本號和修訂號的數值，如 1.0.0 < 1.0.1 < 1.1.1 < 2.0.0；對於先行版本號和開發版本號，有：1.0.0.a100 < 1.0.0，2.1.0.dev3 < 2.1.0；當存在字母時，以 ascii 的排序來比較，如 1.0.0.a1 < 1.0.0.b1。
注意：版本一經發布，不得修改其內容，任何修改必須在新版本發布！
一些修飾的詞
版本號命名指南
首先看看某些常見軟體的版本號 從上可以看出，不同的軟體版本號風格各異，隨著系統的規模越大，依賴的軟體越多，如果這些軟體沒有遵循一套規範的命名風格，容易造成 dependency hell。所以當我們發布版本時，版本號的命名需要遵循某種規則，其中 semantic versioning 2.0.0 定...
GNU版本號命名風格
參考資料 gnu 風格的版本號命名格式 主版本號 子版本號 修正版本號 編譯版本號 英文對照 major version number minor version number revision number build number 示例 1.2.1，2.0，5.0.0 build 13124 g...
介面（Api）版本號命名規則
版本號的命名和更新問題，是開發者的責任感和前瞻性的問題。版本格式 0.0.0 此時系統尚不穩定，隨時可能增減或者修正api。版本格式 0.次版本號.修訂號，版本號遞增規則如下 主版本號 0表示正在開發階段 次版本號 增加新的功能時增加 修訂號 只要有改動就增加。此時系統已經基本穩定，可以對外公布使用...