一、應用版本更迭的必要性

一款產品從無到有，從孵化到呱呱墜地，需要經歷了一個完整的生命週期，這裡麵包括：產品戰略、產品市場、產品規劃、產品需求、產品開發、產品上市、產品市場管理總共7個部分；產品管理則是對產品生命週期進行管理；當產品上市釋出後，隨之而來的每次更迭，修補，新增都是為了產品更加豐滿、健壯、具備競爭力；所以，產品管理中對產品每次版本的定義顯得尤為重要，版本的定義能夠清晰的瞭解每次產品迭代背後的目標和價值，而產品版本編號的變化是產品生命線上每個重要的里程碑，它記錄了產品特性的變化，子產品和子產品的關係變化，產品修復結果的變化等等；好的產品版本管理容易閱讀，方便記憶，能夠明晰各類關係，糟糕的產品版本管理會讓你發現掉進深淵，落入陷阱。當你被版本鎖定或版本穿插所阻撓而不能容易地讓你的專案順利前進時，你就身處依賴地獄中了。  

二、基本原則

如果產品版本依賴定義得過於鬆散，你難免會被版本穿插所傷，因此，用一組簡單的規則和要求來約束版本號的分配和增長規則，你必須預先定義好自己的公共API，這可以通過文件定義或程式碼強制要求來實現。無論如何，這套API的清楚明瞭是十分重要的。一旦你定義了公共API，你就可以通過修改相應的版本號來通知大家你的修改。

1、版本號格式：X.Y.Z（主版本號，次版本號，補丁版本號）

2、修復Bug但不影響API增長補丁版本號；

3、API保持向下相容的增加/修改時增長次版本號；

4、進行不向下相容的修改時增長主版本號。

 

三、產品版本命名規範

1、使用語義版本命名的軟體系統必須定義一套公共API。這套API可以是在程式碼中申明或是用嚴格的文件定義。不管怎樣做，它都應該清楚明瞭。

2、正常的版本號必須使用X.Y.Z的形式並且X/Y/Z是非負整數。X是主版本號，Y是次版本號，Z是補丁版本號。版本號每次必須只能增長1。例如：1.9.0->1.10.0->1.11.0。

3、當主版本號增長時，次版本號和補丁版本號必須清零。當次版本號增長時，補丁版本號必須清零。例如：1.1.9->2.0.0，2.1.7->2.2.0。

4、一旦釋出了具有版本的包，那個版本的內容必須不能再更改。任何修改必須釋出成一個新版本。

5、主版本號0 (0.y.z)是用來進行初始開發時使用的。任何東西都可能在任何時候改變。公共API此時應該被認為是經常變動的。

6、版本1.0.0開始定義公共API。這個版本及以後的版本號的增長方式將依賴於公共API以及它如何變化。

7、如果單一子產品有任何向下相容的bug修復發生，補丁版本號Z (x.y.Z | x > 0)必須增長1。“bug修復”被定義為內部進行的修復非正常行為的修復工作。

8、如果單一子產品進行了新的並且向下相容的公共API新增、優化、修改，次版本號Y (x.Y.z | x > 0)必須增長1。如果任何公共API被標記為“過期”，次版本號必須增長1；如果有大量的新功能或改進在內部程式碼中發生，次版本號可以增長1；這其中也可以包含補丁級別的修改。當次版本號增長時補丁版本號必須清零。

9、如果單一子產品對公共API有任何向下不相容的修改，或者兩個及兩個以上子產品同時釋出新特性，或者主產品開闢新業務模式，主版本號X (X.y.z | X > 0)必須增長1。這其中也可以包含次版本和補丁版本級別的修改。當主版本號增長時次版本號和補丁版本號必須清零。