項目管理中必須注意軟件項目的命名規範：
目前採用GNU 風格的版本號命名格式 :
主版本號 . 子版本號 [. 修正版本號 [. 編譯版本號 ]]
英文對照 : Major_Version_Number.Minor_Version_Number[.Revision_Number[.Build_Number]]
示例 : 1.2.1, 2.0, 5.0.0 build-13124
應根據下面的約定使用這些部分：
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．另外 , 編譯版本號一般是編譯器在編譯過程中自動生成的 , 我們只定義其格式 , 並不進行人爲控制 .
發給測試人員使用的是beta版。 bug修復，迴歸測試通過後，發佈正式版(最終用戶使用正式版)， 生成環境中必須使用正式版。
beta以後，後續版本可以是Gamma, Current, RC (Release Candidate), Release, Stable 等,
也可以在後面加入 1 位數字的版本號, 比如RC-1, RC-2, RC-3.
部分轉自：http://blog.csdn.net/destiny0714/archive/2007/05/17/1612587.aspx