專案管理中必須注意軟體專案的命名規範：
目前採用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
軟體專案版本命名規範
from 目前採用gnu 風格的版本號命名格式 主版本號 子版本號 修正版本號 編譯版本號 英文對照 major version number.minor version number revision number build number 示例 1.2.1,2.0,5.0.0 build 131...
軟體版本命名規範
1.軟體版本階段說明 base版 此版本表示該軟體僅僅是乙個假頁面鏈結，通常包括所有的功能和頁面布局，但是頁面中的功能都沒有做完整的實現，只是做為整體 的乙個基礎架構。alpha版 此版本表示該軟體在此階段主要是以實現軟體功能為主，通常只在軟體開發者內部交流，一般而言，該版本軟體的bug較多，需要繼...
軟體版本命名規範
1.版本命名規範 軟體版本號有四部分組成，第一部分為主版本號，第二部分為次版本號，第三部分為修訂版 本號，第四部分為日期版本號加希臘字母版本號，希臘字母版本號共有五種，分別為base alpha beta rc release 步驟閱讀 22.軟體版本階段說明 alpha 軟體的初級版本，表示該軟體...