軟體專案版本號的命名格式

本文**於：

版本控制比較普遍的 3 種命名格式 :

一、 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 位數字的版本號 .

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

附： alphal 內部測試版

// 本文** c++builder 研究 - article.asp?i=1006&d=6074sk