軟件項目版本號的命名規則及格式介紹

　　一、GNU 風格的版本號命名格式 :

　　主版本號 . 子版本號 [. 修正版本號 [. 編譯版本號 ]]

　　英文對照 : Major_Version_Number.Minor_Version_Number[.Revision_Number[.Build_Number]]

　　示例 : 1.2.1, 2.0, 5.0.0 build-13124

　　二、Windows 風格的版本號命名格式 :

　　主版本號 . 子版本號 [ 修正版本號 [. 編譯版本號 ]]

　　英文對照 : Major_Version_Number.Minor_Version_Number[Revision_Number[.Build_Number]]

　　示例: 1.21, 2.0

　　三、.Net Framework 風格的版本號命名格式:

　　主版本號.子版本號[.編譯版本號[.修正版本號]]

　　英文對照: Major_Version_Number.Minor_Version_Number[.Build_Number[.Revision_Number]]

　　版本號由二至四個部分組成：主版本號、次版本號、內部版本號和修訂號。主版本號和次版本號是必選的；內部版本號和修訂號是可選的，但是如果定義了修訂號部分，則內部版本號就是必選的。所有定義的部分都必須是大于或等于 0 的整數。

　　應根據下面的約定使用這些部分：

　　Major ：具有相同名稱但不同主版本號的程序集不可互換。例如，這適用于對產品的大量重寫，這些重寫使得無法實現向后兼容性。

　　Minor ：如果兩個程序集的名稱和主版本號相同，而次版本號不同，這指示顯著增強，但照顧到了向后兼容性。例如，這適用于產品的修正版或完全向后兼容的新版本。

　　Build ：內部版本號的不同表示對相同源所作的重新編譯。這適合于更改處理器、平臺或編譯器的情況。

　　Revision ：名稱、主版本號和次版本號都相同但修訂號不同的程序集應是完全可互換的。這適用于修復以前發布的程序集中的安全漏洞。

　　程序集的只有內部版本號或修訂號不同的后續版本被認為是先前版本的修補程序 (Hotfix) 更新。

　　版本號管理策略

　　一、 GNU 風格的版本號管理策略：

　　1．項目初版本時 , 版本號可以為 0.1 或 0.1.0, 也可以為 1.0 或 1.0.0, 如果你為人很低調 , 我想你會選擇那個主版本號為 0 的方式 ;

　　2．當項目在進行了局部修改或 bug 修正時 , 主版本號和子版本號都不變 , 修正版本號加 1;

　　3. 當項目在原有的基礎上增加了部分功能時 , 主版本號不變 , 子版本號加 1, 修正版本號復位為 0, 因而可以被忽略掉 ;

　　4．當項目在進行了重大修改或局部修正累積較多 , 而導致項目整體發生全局變化時 , 主版本號加 1;

　　5．另外 , 編譯版本號一般是編譯器在編譯過程中自動生成的 , 我們只定義其格式 , 并不進行人為控制 .

　　二、 Window 下的版本號管理策略：

　　1．目初版時 , 版本號為 1.0 或 1.00;

　　2. 當項目在進行了局部修改或 bug 修正時，主版本號和子版本號都不變 , 修正版本號加 1;

　　3. 當項目在原有的基礎上增加了部分功能時 , 主版本號不變 , 子版本號加 1, 修正版本號復位為 0, 因而可以被忽略掉 ;

　　4. 當項目在進行了重大修改或局部修正累積較多 , 而導致項目整體發生全局變化時 , 主版本號加 1;

　　5. 另外 , 編譯版本號一般是編譯器在編譯過程中自動生成的 , 我們只定義其格式 , 并不進行人為控制 .

　　另外 , 還可以在版本號后面加入 Alpha, Beta, Gamma, Current, RC (Release Candidate), Release, Stable 等后綴 , 在這后綴后面還可以加入 1 位數字的版本號 .

　　對于用戶來說 , 如果某個軟件的主版本號進行了升級 , 用戶還想繼續那個軟件 , 則發行軟件的公司一般要對用戶收取升級費用 ; 而如果子版本號或修正版本號發生了升級 , 一般來說是免費的 .

原文轉自：http://www.kjueaiud.com