尋找針對軟件版本的建議版本風格

Question

我開發了一個名爲nearforums的開源論壇引擎（http://nearforums.codeplex.com/），我希望得到關於如何命名版本的建議。

到現在爲止，釋放被命名爲release1，release2等，但在接下來的幾天，我會作出新的版本，我不知道這是否是跟隨releaseN命名一個好主意......

我應該遵循mayor.minor版本風格嗎？如何選擇第一個「mayor.minor」和當前？如何處理錯誤修復+發佈？

每次開發幾個「大」功能時，我都會繼續發佈。

感謝您的諮詢！

Answer 1

問5個開發人員，你可能會得到6個不同的版本編號建議。

無論您選擇哪個版本號系統，都應該確保它遵循特定的指導原則。大多數軟件包管理系統都希望能夠確定哪一個版本是最新版本，所以您應該確保您的版本號系統始終在增加，其中第一個數字的優先級最高，第二個數字的優先級最高，等等。例如，如果您'現在在版本3上，如果你決定使用XY系統，那麼你不應該退化爲1.4，你至少應該從3.1或4.0開始。大多數軟件包管理系統都有一些時代的概念來修復這樣的情況，在這種情況下版本號會倒退，但是你不應該依賴這種情況。

一般來說，您的版本號應該由虛線數字組成，每個數字以數字順序遞增（因此，1,2,3，...，9,10,11 ...，而不是按字典順序排序） 1，10，11，2，3，...）。

有些人喜歡使用major.minor.patch系統，其中向後兼容更改或主要新功能的主號碼增量，向後兼容更改或次要新功能的次號增量以及修補程序更改僅適用於不引入任何新功能的向後兼容錯誤修正。

其他人喜歡使用Ubuntu系統，year.month或year.release（可能還有第三個數字以及補丁或錯誤修正，或year.month.day）。這可以幫助避免必須確定什麼構成「主要」功能，並且可以給人們一個比任意的「7」或「23」更令人難忘的數字。這有一個缺點，即不讓用戶知道何時做出向後不兼容的更改，儘管取決於您正在做什麼，可能不太相關（如果您始終保持向後兼容性，或者如果您編號爲Linux包含很多部分的發行版，其中一些可能是向後兼容的，其中一些可能不會，從而保證版本之間的向後兼容性並不合理）。

如果您覺得您可以承諾強烈的向後兼容性概念，我建議您使用一個major.minor.patch系統，遵循Semantic Versioning中給出的指導原則。在這些指導原則中，您將增加主要版本以應對不兼容的更改。您可以增加次要版本以實現向後兼容的更改，這些更改可能仍會增加新功能（所以有人可能依賴於大於2.3.0的版本，因爲這是添加了新功能的版本，但小於3.0.0，因爲它可能具有不兼容的變化）。您只爲錯誤修正增加該修補程序級別。如果你現在正在使用第3版，我會在4.0.0版本開始你的下一個版本，然後從現在開始遵循這個模型。

如果您不喜歡做工作以確保兼容性並確定什麼是和不是向後兼容的，那麼只需使用year.month，year.month即可。版本或year.version版本，其中版本在該月份或年份內每次發佈增加1（取決於發佈頻率）。因此，您的下一個版本將會像2010.1，2010.8.1或2010.8一樣，具體取決於確切的表單（或者您可以使用10.1,10.8.1等）。

（嗯，我只是一個開發人員，我想我現在給你至少6個選項。哦，希望他們中的一個爲你的作品）