使用什麼版本編號方案？

我正在尋找一個版本編號方案來表達變化的程度，尤其是兼容性。使用什麼版本編號方案？

Apache APR，例如，使用衆所周知的版本編號方案

<major>.<minor>.<patch> 
example: 4.5.11

Maven的建議類似，但更爲詳細的架構：

<major>.<minor>.<patch>-<qualifier>-<build number> 
example: 4.5.11-RC1-3732

凡被定義Maven的版本控制方案？是否有限定符和內部編號的約定？可能使用maven但不遵循Maven版本方案是一個糟糕的主意......

你知道哪些其他版本編號方案？你更喜歡什麼方案？爲什麼？

來源

2010-01-12 deamon

會http://stackoverflow.com/questions/1889615/version-numbering-basics幫助嗎？ – VonC 2010-01-12 11:22:24

這裏是current Maven version comparison algorithm和它的discussion。只要版本只是增長，並且除了內部版本號之外的所有字段都是手動更新的，那麼您就很好。限定符的工作方式如下：如果其中一個是另一個的前綴，則更長一些。否則，它們按字母順序進行比較將它們用於預發佈。

借用語義版本化來表達兼容性;主要用於非向後兼容的更改，次要用於向後兼容的功能，補丁用於向後兼容的錯誤修正。記錄它，以便您的圖書館用戶可以正確表達對圖書館的依賴關係。你的快照是自動的，不必增加這些，除了因爲比較前綴的方式而在發佈之後的第一個快照之外。

來源

2010-01-12 11:27:55 Tobu

我會推薦Semantic Versioning標準，Maven版本控制系統也會遵循這個標準。請看看，

http://semver.org/

總之它是<major>.<minor>.<patch><anything_else>，並可以作爲似乎適合你添加其他規則的任何其他部分。例如。 -<qualifier>-<build_number>。

來源

2010-01-12 11:37:37 sixohsix

- - Maven的方案似乎並不完全匹配semver.org recommondation。 semver.org：「一個特殊的版本號可以通過在補丁版本後緊跟一個任意的字符串**來表示，字符串必須只包含字母數字加破折號[0-9A-Za-z-]和**必須以字母字符[A-Za-z] **開始。「 – deamon 2010-01-12 19:12:19

@deamon semver.org可能在幾年前改變了它，但爲了記錄它現在符合maven方案：「預發佈版本可以通過在補丁版本後立即追加連字符和一系列點分隔標識符來標識。必須僅包含ASCII字母數字和連字符[0-9A-Za-z-]。標識符不能爲空。數字標識符不得包含前導零。「 – Kapep 2014-11-30 15:26:21

@kapep：格式仍不完全兼容，因爲比較算法來自semver比Maven使用的要複雜得多。但如果你堅持只是「-RC1」，「-RC2」或類似的，你應該沒問題。 – sleske 2015-11-13 08:39:43

閱讀的文章很多/質量檢查/常見問題/書籍後，我變得想是[MAJOR] [MINOR]。[REV]是最有用的版本架構描述的項目版本之間的兼容性（版本架構爲開發人員，不用於營銷）。

主要變化是落後的不兼容，需要更改項目名稱，路徑文件的GUID等

MINOR變化是向後兼容。馬克介紹新的功能。

REV安全/錯誤修復。向後和向前兼容。

通過的libtool版本語義靈感此版本的架構和文章：

http://www106.pair.com/rhp/parallel.html

注：我還建議提供編譯/日期/自定義/質量作爲附加信息（建號，生產日期，客戶名稱，發佈質量）：

您好應用v2.6.34爲國家銀行，2011-05-03，公測，建立

但是這個信息是不版本信息！

來源

2011-10-11 18:24:00 gavenkoa

純粹的完整性，我會提old Apple standard for version numbers。這看起來像主版本。 小版本。 錯誤版本。階段。 非版本修訂版。第一階段是從集合d（發展），一個（阿爾法），b（測試版），或FC繪製的代碼（最終客戶艦 - 或多或少相同的發佈候選，我想）。

階段版本和非版本修訂僅用於短版本的版本。

所以，事物的第一個版本可能是1.0.0。你可能已經發布了bug修正爲1.0.1，新版本（具有更多功能）爲1.1，重寫或主要升級爲2.0。如果你想要朝着2.0.1努力，你可能會從2.0.1d1,2.0.1d2，2.0.1d153開始，或者你需要的任何東西，然後發送2.0.1a1到QA，並且在他們批准2.0.1a37之後，將2.0.1b1發送給一些願意投注的玩家，然後在2.0.1b9在該領域存活一週後，燒錄2.0.1fc1並開始獲得簽名。當2.0.1fc17得到足夠的時候，它會變成2.0.1，並且會有很多歡樂。

這種格式已經足夠標準化，以至於有一個打包的二進制格式和庫中的輔助例程進行比較。

來源

2012-04-27 16:09:34

純粹爲了完整性（:-)），我想指出，恕我直言，需要爲每個階段（這個方案暗示）單獨構建不是一個好主意。至少最終的QA /測試版本應該在生產中保持不變。任何行爲差異都應通過配置注入。見例如[單獨'調試'和'發佈'生成？]（http://stackoverflow.com/questions/420343/separate-debug-and-release-builds）。 – sleske 2015-11-13 08:44:05

@sleske我不認爲它確實意味着每個階段都有獨立的構建。如果您正處於beta測試階段，那麼您將在dev中創建1.2.3b4，通過CI放置它，讓QA批准它，執行UAT，然後將其推廣到Beta測試人員，一直使用相同的二進制文件。相反，它意味着在任何時候，你都知道構建可能會走多遠 - 所以你知道你什麼時候提交它只會用於開發，發送給beta測試者，發佈等等。轉換時有一些重複例如，如果1.2.3b10通過beta測試，相同的代碼可能會變成1.2.3fc1，這並不理想。 – 2015-11-15 10:56:15

請注意，版本號方案（如x.y.0與x.y）可能受到外部因素的限制。

考慮到announcement for Git 1.9 (Januaury 2014)：

候選發佈版的Git V1.9-RC2現在可以在平時的地方測試。

我聽到傳言說，各種第三方工具不喜歡兩位數的版本號（例如，「混帳2.0」），並開始barfing左右當用戶安裝V1.9-RC1 。
雖然它試圖在他們笑自己馬虎的假設，我也很實用，不介意調用即將發佈v1.9.0幫助他們。

如果我們走這條路（和我傾向於走在這時，路徑），版本控制方案將是：

下一個候選發佈版將是v1.9.0-rc3，不v1.9-rc3;

第一維護版本爲v1.9.0將v1.9.1（和第N個一個是v1.9.N）;和

v1.9.0之後的功能版本將爲v1.10.0或v2.0.0，具體取決於我們正在查看的功能跳躍有多大。

來源

2014-02-04 07:30:33 VonC

使用什麼版本編號方案？

回答

相關問題