# 版本號 在我們討論如何發布之前，首先看一下如何命名版本，用戶需要從版本中知道什么。一個版本發布意味著： - 老的bug被修正了。恐怕所有的用戶都認為每個版本都理所當然應該做到這一點。 - 會帶來新bug。一般情況下這是必然的，除非是安全版本或其他特殊情況（見本章后面[the section called “安全發布”](# "安全發布")）。 - 也加入了新的特性。 - 新配置選項也會被添加，或者一些以前的選項有了微妙的變化。和上個版本相比，安裝步驟可能有輕微的調整，即使人們不希望這樣。 - 也可能帶來不兼容的變化，例如以前版本的軟件所用的數據格式必須做出某種（可能是手工的）單向的轉化，才能繼續使用。 就像你看到的，發生的不都是好事。這就是為什么經驗豐富的用戶總是對新版本保持恐懼，特別是當軟件已經足夠成熟，已經能夠滿足他們的需要時（或者認為他們滿足了）。即使新特性是好壞參半的事情，也意味著軟件現在可能以不可預期的方式運行。 因此發布版本編號的目的是雙重的：很明顯這個編號可以在交流中明確發布的順序（例如，通過比較兩個版本號，你可以看出哪個版本更老），另一方面，也應該盡可能緊湊的表明該發布所帶來變更的程度和性質。 僅僅是號碼嗎？或多或少是。版本編號策略是最古老的自行車庫討論（見[Chapter?6, *交流*](# "Chapter?6.?交流")的[the section called “主題越軟，辯論越長”](# "主題越軟，辯論越長")），這個世界也似乎從來沒有能達成一個單獨的完整的標準。然而，還是出現了一些好的策略，依據了一些廣泛認同的原理：*一致性*。采取一種編號方式，記錄下來，并堅持使用。你的用戶會感激不盡。 ### 版本號組成部分 本小節詳細描述了一些發布版本號的正式慣例，認為是已知的預先知識。目的僅僅是作為一個參考。如果你已經了解了這些慣例，你可以跳過本小節。 發布號碼是一組點分割的數字： Scanley?2.3 Singer?5.11.4 ...等等。這些點*不是*小數點，而僅僅是分隔符；“5.3.9”之后將會是“5.3.10”。某些項目偶爾也會用其他的提示，例如非常有名的Linux內核，在Linux 1.0之前使用的是“0.95”、“0.96”... “0.99”，但是這種點號成為了固有的習慣，已經被認為是一種標準。數字部分（不包含點的數字部分）的數量沒有限制，但是大多數項目不應該超過3或4。在后面我們會對原因有更清楚的認識。 除了數字部分之外，一些項目也會附加一個描述標簽，例如“Alpha”或“Beta”（見[Alpha和Beta](# "Alpha和Beta")），例如： Scanley?2.3.0?(Alpha) Singer?5.11.4?(Beta) Alpha或Beta修飾意味著這個版本是一個將要發布版本（同樣的版本號，但沒有修飾）的*先例*。因此，“2.3.0?(Alpha)”將會帶來“2.3.0”。為了能排列好多個這樣的候選版本，修飾符也可以有一個之后的修飾。例如，下面是一系列即將發布的版本，根據發布時間排序： Scanley?2.3.0?(Alpha?1) Scanley?2.3.0?(Alpha?2) Scanley?2.3.0?(Beta?1) Scanley?2.3.0?(Beta?2) Scanley?2.3.0?(Beta?3) Scanley?2.3.0 請注意當使用“Alpha”修飾符時，Scanley的"2.3"寫作"2.3.0"。這兩個號碼是等同的—出于簡短的目的，結尾所有的0都可以丟掉—但是當有修飾詞時，簡短成為無需考慮的問題，所以人們會選擇完整的方式。 另外一些半正規的修飾詞包括“Stable”、“Unstable”、“Development”和“RC”（“發布候選”）。最常用的還是“Alpha”和“Beta”，而“RC”用于第三方，但是請注意“RC”總會包含一個數字修飾。也就是不要使用“Scanley?2.3.0?(RC)”，而使用“Scanley?2.3.0?(RC?1)”，然后是RC2，以此類推。 “Alpha”、“Beta”和“RC”都是已經廣為人知的標簽了，所以我不建議你使用其他標簽，即使是那些乍看起來更常見而非方言的詞匯，似乎是更好的選擇。但是那些從發布包安裝軟件的人對于這三個詞匯已經非常熟悉，沒有理由選擇特立獨行。 盡管發布版本號碼中的點數并不是小數點，但也是起到了位置標示的作用。所有的“0.X.Y”早于“1.0”（等同于“1.0.0”）。“3.14.158”是“3.14.159”直接前繼版本，而“3.14.160”和“3.15.任意數”則是“3.14.158”的后繼版本，擔不是直接后繼。 一致的發布版本號碼策略可以讓用戶僅僅從某個軟件的版本號就可以判斷出版本的重要程度。在一個三部分的系統中，第一部分是*主?版本號*，第二部分是*次?版本號碼*，而第三部分是*小?版本號碼*。例如版本“2.10.17”是主版本2系列的次要版本10開發線的小版本17。詞匯“開發線”和“系列”在這里并不正式，但他們代表了人們期望的含義。一個主系列僅僅是共享同一個主號碼的版本，而次要系列（或次要開發線）則由相同次要*和*主號碼的版本。也就是說，“2.4.0”和“3.4.1”并不是位于同一個次要系列，即使他們都有次要版本號碼4。另一個情況下，“2.4.0”和“2.4.2”則位于同一個次要開發線，盡管他們并不是相鄰的版本，因為“2.4.1”版本位于他們之間。 這些號碼的含義可以是你自己所期望的：主號碼的變更表示發生了主要的變化；次要號碼的變化表示發生了次要的變更。有一些項目會有第4部分，通常叫做*補丁?號碼*，特別是一些對區別進行細致控制的項目（有一點讓人混淆的是，一些項目將三部分系統中的“微（micro）”版本作為“補丁”。）。也有一些項目使用最后一部分作為*構建?號碼*，隨著項目的每一次構建遞增，代表了每次變更的變化。這樣幫助了項目將每個bug報告與特定構建聯系起來，特別是當二進制發布包是發布默認方法時特別有用。 盡管對于使用多少個部分，每個部分的含義有許多不同的習慣，區別通常很小—你會受到一些壓力，但是不會太大。下面兩小節討論了最常用的幾個習慣。 ### 簡單策略 如果僅僅會改變微小版本號碼，大多數項目對于將何種變更納入到發布中會有一些規則，改變主要版本號碼則也會有相應的規則。沒有這些規則的標準集合，但下面描述是已經在許多項目廣泛使用的的政策。你或許會在自己的項目中采用這些方法，但即使不使用，這仍是發布號碼所應傳達信息的好案例。這個政策是APR項目使用的編號系統，請看[http://apr.apache.org/versioning.html](http://apr.apache.org/versioning.html)。 1. 對于微小號碼的變更（也就是在同一個次要開發線上發生的變化）只能是向前和向后兼容的。也就是說，變更只能是bug修正，或僅僅是對現有特性較小的改進。新特性一定不能在微小版本發布中引入。 1. 次要版本號碼（也就是位于同一個主開發線）的變更必須是向前兼容，但不必向后兼容。在次要版本中引入新特性非常常見，但是通常不要一次包含過多特性。 1. 主版本號碼的變更標識了兼容性的邊界。新的主版本發布不必向前和向后兼容。新的主版本發布應該包含新的特性，甚至完全的新特性集合。 *向后兼容*和*向前兼容*的含義取決于你的軟件，但通常無需明確的解釋。例如，如果你的項目是客戶端/服務器應用，那么“向后兼容”意味著將服務器升級到2.6.0不會導致2.5.4的客戶端失效，或者工作方式發生變化（當然要排除修正的bug）。另一方面，將客戶端升級到2.6.0，可以讓客戶端享受2.5.4無法使用*新*功能。如果不能做到這一點，則升級*不是*“向前兼容”：顯然，你現在不能將客戶端降級到2.5.4，并保持2.6.0的功能，因為一些功能是2.6.0新增的。 這也是微小版本主要用于bug修正的原因。一定要保持雙向的兼容性：如果你從2.5.3升級到2.5.4，然后改變主意降級到2.5.3也不會有任何功能損失。當然，2.5.4中修正的bug會再次出現，但不會損失任何新特性，只是bug可能會妨礙現有特性的使用。 客戶端/服務器協議僅僅是許多可能的兼容性領域的一種情況。另一種是數據格式：軟件會將數據寫入永久存儲嗎？如果是，則數據的寫入和讀取必須依照發布號碼政策所承諾的兼容性方針。版本2.6.0需要能夠讀取2.5.4寫的文件，但是可能會暗自將格式升級到2.5.4無法閱讀的新格式，因為跨次要版本邊界的無需有降級的能力。如果其他程序使用你的項目發布的代碼庫，則API也是需要考慮的兼容性領域：你必須確保明確說明源代碼和二進制兼容性規則，用戶無需擔心直接升級是否安全。她應當可以通過版本號碼立刻知道結果。 在這個系統中，只有增加主版本號碼時你才能從頭開始。這確實有些不便：也許你會希望增加某些特性，希望重新設計協議，但是為了維護兼容性而無法實現。這個問題沒有魔法解決方案，除非你能在一開始就以可擴展的方式進行設計（值得用單獨一本書討論的主題，當然超出了本書的范圍）。但是通過公布發布兼容性政策，并遵守它，是發布軟件不能回避的一部分。某個低劣的驚奇只會疏遠許多用戶。剛剛描述的政策能起到的作用有限，因為它已經廣泛傳播，但是因為它易于解釋和記憶，所以不熟悉的人也可以很快接受。 也需要知道上述規則并不適用于pre-1.0的版本（盡管您的發布政策應當明確陳述，只是要說清楚）。一個還處于初始發布狀態的開發可以發布0.1、0.2、0.3以及依次的后續版本，直到1.0，這些發布之間的區別可以任意大。pre-1.0版本的微小版本號可以省略。取決于項目的特性和版本的區別，你或許會發現0.1.0、0.1.1也很有效。pre-1.0的版本號碼規則通常比較松散，主要是因為人們明白在項目初期，較強的兼容性限制會嚴重阻礙開發，而且較早的使用者也較能夠容忍這種變化。 請牢記所有這些指令僅適用于三部分系統。你的項目可以輕易的得到不同的三部分系統，甚至可以決定不使用這么細致的粒度，而僅僅使用兩部分系統。重要的是要盡早決定，僅按照每個部分的含義發布，并堅持下去。 ### 奇偶數策略 一些項目使用次要版本號碼部分表示項目的穩定程度：偶數表示穩定，奇數表示不穩定。僅適用于次要版本號碼，不能用于主版本號碼和微小版本號碼。微小版本號碼依然表示bug修正（沒有新特性），主版本號碼的遞增依然表示重大變更，新特性集合。 奇偶系統優勢在于它已經被Linux內核項目使用，它提供了一種方法，可以發布新功能用于測試，而無需讓產品用戶受到潛在不穩定代碼的影響。人們在看到“2.4.21”時可以認為能夠用于他們使用的web服務器，但當看到“2.5.1”時，則可以用于家用工作站的實驗中。開發團隊掌握了來自不穩定（奇數次要版本號碼）系列的bug報告，當在該系列的一些微小版本中完成了許多工作后，他們便增加次要版本號碼（變成偶數），將微小版本號碼恢復到“0”，并發布推定的穩定包。 這個系統保留了前面給定的兼容性政策，或至少沒有發生沖突。僅僅是在次要版本號碼上重載了一些額外的信息。僅僅是讓需要的人每次需要增加兩個次要版本號碼，并沒有重大的損害。奇偶系統通常最適合用于擁有較長發布周期的項目，以及因為本性上就需要較高比例的保留用戶能為新特性評估穩定性的項目。當然這不是讓新功能得以測試的唯一方法，本章后面的章節[the section called “穩定發布版本”](# "穩定發布版本")描述了另一個方法，也是更常見的公布不穩定代碼的方法，直接通過發布名稱的標識讓人們知曉風險/收益的代價。