版本號的命名和更新問題，是開發者的責任感和前瞻性的問題。
版本格式：0.0.0此時系統尚不穩定，隨時可能增減或者修正api。
版本格式：0.次版本號.修訂號，版本號遞增規則如下：此時系統已經基本穩定，可以對外公布使用，意味著api不再會被隨意修改。主版本號：0表示正在開發階段；
次版本號：增加新的功能時增加；
修訂號：只要有改動就增加。
版本格式：1.0.0沒有特殊需求不會修改api，尤其是對api進行不相容的公升級，或棄用時要特別謹慎。如果需要棄用api，要提前在乙個或幾個版本中加入棄用標示或註解，並在文件中，建議使用者更換為其他可替換的api，然後在下個主版本號公升級時，再真正丟掉棄用的api。
版本格式：主版本號.次版本號.修訂號，版本號遞增規則如下：新增介面：如果該新增的介面只是對現有的業務線進行擴充套件則增加修訂號；如果是為了增加新的業務線則增加次版本號。主版本號：全盤重構時增加；重大功能或方向改變時增加；大範圍不相容之前的介面時增加；
次版本號：增加新的業務功能時增加；
修訂號：增加新的介面時增加；在介面不變的情況下，增加介面的非必填屬性時增加；增強和擴充套件介面功能時增加。
先行版本號及版本編譯資訊可以加到「主版本號.次版本號.修訂號」的後面，作為延伸。
先行版本號(pre-release)：意味該版本不穩定，可能存在相容性問題。 其格式為：x.y.z.[a-c][正整數]，如 1.0.0.a1，1.0.0.b99，1.0.0.c1000。1. 版本一經發布，不得修改其內容，任何修改必須在新版本發布！開發版本號：常用於 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。
2. 在介面還沒有確定下來的時候，應該先使用開發版本號。
3. 業務功能 > 功能 > 介面
推薦閱讀：版本號命名指南
版本號命名規則-語義化版本 2.0.0 | semantic versioning
軟體版本號規則和命名規則
1.軟體版本階段說明 obase 版 此版本表示該軟體僅僅是乙個假頁面鏈結，通常包括所有的功能和頁面布局，但是頁面中的功能都沒有做完整的實現，只是做為整體 的乙個基礎架構。o alpha 版 此版本表示該軟體在此階段主要是以實現軟體功能為主，通常只在軟體開發者內部交流，一般而言，該版本軟體的bug較...
版本號命名指南
首先看看某些常見軟體的版本號 從上可以看出，不同的軟體版本號風格各異，隨著系統的規模越大，依賴的軟體越多，如果這些軟體沒有遵循一套規範的命名風格，容易造成 dependency hell。所以當我們發布版本時，版本號的命名需要遵循某種規則，其中 semantic versioning 2.0.0 定...
版本號命名指南
首先看看某些常見軟體的版本號 從上可以看出，不同的軟體版本號風格各異，隨著系統的規模越大，依賴的軟體越多，如果這些軟體沒有遵循一套規範的命名風格，容易造成 dependency hell。所以當我們發布版本時，版本號的命名需要遵循某種規則，其中 semantic versioning 2.0.0 定...