一個良好的版本號的結構和改動規則，向用戶傳達了我們軟件改動的影響級別。版本號標准依據Semantic Versioning 2.0.0，適用於APP，API，代碼分支歸檔等。
Semantic Versioning 規范
- 版本號必須使用x.y.z格式，且均為正數。版本號的每個元素必須以正整數遞增。
- x 主版本號
- y 次版本號
- z 補丁版本號
- 示例： 1.9.0 -》 1.10.0 -》1.11.0
- 一旦一個版本打包發布出去了，那么版本的內容就不能更改了。任何更改必須作為一個新的版本重新發布。
- 主版本為0（0.x.y）的版本作為開發初始階段。任何東西都可能在任何時間修改，這個時候我們認為它是不穩定的。
- 1.0.0表明正式對外API公開版本的形成。從此版本號的遞增取決於這個公開的API。
- 補丁版本號（x.y.z | x>0）,如果只有向后兼容的BUG被修復，補丁版本號必須遞增。
- 次版本號（x.y.z | x>0）
- 如果一個新的，向后兼容的功能被引入到公開API里，次版本號必須遞增。
- 如果公開API的任何功能被標記為“已棄用”，次版本號必須遞增。
- 如果大量新的功能被引入私有代碼里面，次版本號可以遞增。
- 次版本號遞增的時候，補丁號必須歸零。
- 主版本號（x.y.z | x>0）任何向后不兼容的改動被引入到公開API中，主版本號必須遞增。它的遞增可以包含次版本和補丁級的改動。當它改動的時候，次版本號和補丁號必須歸零。
- 一個預發布版本可以在補丁版本號后追加一個短線，以及一個用點分割標識來描述。例子: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7
- 版本優先級比較：“主版本號”，“次版本號”，“補丁號”，以數字方式比較，例子：1.0.0<2.0.0<3.0.0
- 如果有2個預發布版本號一致的時候，預發布版本比正常版本優先級低。例子：1.0.0-alpha < 1.0.0
FAQ
在開發初始階段，怎么處理0.y.z版本號？
一個簡單的做法是將0.1.0作為第一個版本號，然后為隨后的版本遞增發布。
我怎么知道發布的版本是1.0.0？
當軟件已經在生產環境上線了，那么我們通常定義為1.0.0。
如何處理即將棄用的功能？
棄用功能是軟件向前開發中很正常的，通常也是必須的。當棄用API的時候應該做如下兩件事：
- 更新文檔讓使用者知道這個事情。
- 發布一個新的，仍舊包含舊API的次版本，讓使用者平滑遷移到新版本。