# 穩定發布版本 *穩定化*是讓一個發布分支進入發布狀態的過程；也就是決定哪些變更將會進入發布版本，并以此為根據修整分支的內容。 “決定”一詞有許多潛在的不幸。在協作軟件項目中最后一分鐘特性沖擊是非常常見的現象：當開發者看到軟件發布將要發生，他們便混亂的結束當前的變更，不希望錯過這班船。當然，這是在發布時你最不想看到的場面。如果人們能在比較以舒適的節奏，無需擔心變更是進入這個版本還是下一個版本時完成這個特性，效果會更好。設法在最后一分鐘進入發布的變更越多，代碼就越不穩定，而且（通常是）也會造成更多的新bug。 大多數軟件工程師認可在穩定階段，變更進入發布版本線時使用嚴苛標準的理論。很明顯，對于嚴重bug，尤其是沒有臨時解決辦法的bug的修正應該進入。文檔更新以及錯誤信息修改（除非是被認為是界面的一部分，并必須保持穩定的信息）也沒問題。許多項目也允許特定類型的低風險或非核心變更在穩定期進入，并提供評估風險的正式指導。但是沒有正式的文檔可以回避對于人們判斷的需要。在很多情況下項目需要為是否將哪個變更納入發布作出決定。危險的是因為每個人都希望看到自己喜歡的變更進入發布版本，并會激發足夠的人贊成這個變更，而不會激發足夠的反對者。 因此，穩定一個發布版本也就是要創建一種說“不”的機制。對于開源項目來說，技巧在于如何能在說“不”的同時，盡可能避免造成過多的情緒傷害或失望的開發者，并且還要防止在發布版本中漏掉真正需要的變更。當然有許多不同的方法。可以很容易的設計一個滿足這個標準的系統，只要項目能夠將其視作重要的標準。在廣闊的范圍中，這里我僅僅介紹兩種最流行的系統，希望這不會讓你失去在項目中發揮創造性的激情。有足夠多的其他方式也是可能的；但這兩個是我在實踐中使用過的。 ### 發布所有者獨裁 團隊認可讓某人成為*發布所有者*。這個人可以最終確定進入發布版本的變更。當然，有研討和辯論也是正常和可以設想的，但是最后團隊必須賦予所有者足夠的權威作出最終的決定。對于此類系統，必須選出一個合適的人，具備理解所有變更的技術能力，具備在避免傷害過多感情的情況下將討論引入發布的社會威望和社交技巧。 發布所有者場景會說“我不認為這個變更有什么錯誤，只是我們沒有足夠的時間測試，所以不能進入這個發布版本。”如果發布所有者對于項目具備廣泛的技術知識將會非常有益，這樣可以解釋為什么這個變更會潛在的導致不穩定性（例如，當與軟件的其他部分交互時，或移植性考慮等）。人們有時會為這類決定辯護，或者質問什么樣的變更沒有這種風險。這種對話不需要是對抗性的，只要發布所有者認為所有的論點都是客觀的，而不是條件反射式的堅定自己的立場。 需要注意的是發布所有者與項目領導不必是同一個人（如果有項目領導的話，見[Chapter?4, *社會和政治的基礎架構*](# "Chapter?4.?社會和政治的基礎架構")的[the section called “慈善獨裁者”](# "慈善獨裁者")）。實際上，有時要確保他們*不是*同一個人。成為一個優秀項目領導的技巧與成為優秀發布所有者的技巧并不一定相同。在有些時候，與發布過程同等重要的是能有一個人可以成為項目領導判斷力的平衡力量。 發布所有者角色與較弱獨裁者角色的比較本章后面的[the section called “發布經理”](# "發布經理")。 ### 變更表決 發布所有者獨裁方式的另一個極端就是為進入發布的變更進行表決。然而，因為發布穩定化最重要功能是*排除*變更，所以勢必要設計一種表決系統，只有在大多數開發者表示正面意見時才將變更納入發布。只有比簡單多數更多的贊成才可以引入一個變更（見[Chapter?4, *社會和政治的基礎架構*](# "Chapter?4.?社會和政治的基礎架構")的[the section called “誰進行表決？”](# "誰進行表決？")）。否則，一個人提出，沒有人反對，一個變更就足以進入發布，一個不幸的變化就是每個開發者都會提出自己的變更，而且處于防止他人報復的原因，他們也不會再反對其他人提出的變更。為了避免這個情況，必須安排一些開發者組成子團隊，起到將變更納入發布的協作作用。這并不是意味著讓更多的人評審每個變更，而是為了減少每個單獨的開發者在反對某個變更時的猶豫，因為她知道贊成該變更的所有人不會將她的反對意見當作人身攻擊。子團隊參與的人數越多，討論就會更加集中與變更本身，而不會是關于某個人。 我們在Subversion項目中使用的系統達到了非常好的平衡，所以我在這里將會推薦它。為了讓一個變更進入發布分支，必須至少有3位開發者要投票贊成它，而且沒有反對者。一個單獨的“反對”票足以阻止變更的進入；在發布場景中一個“反對”票等同于否決票（見[the section called “否決權”](# "否決權")）。很自然，這類表決必須伴隨著辯護意見，而且如果有足夠多的人認為辯護毫無道理，也可以發起一次針對該變更的特別表決。在實踐中，這種情況還沒有發生過，我也不認為將會發生。人們面對發布時總是趨向于保守，當人們感到可以否決某個變更時，通常是因為有了足夠好的理由。 因為，發布規程故意傾向于保守，所以否決時的辯護有時是出于程序上的原因，而非技術上的。例如，一個人認為某個變更寫的很好，不太可能導致新bug，但是否決它進入微小版本的意見僅僅是它太大了—或許它引入了新特性，又或者它以微妙的方式違反了兼容性政策。我也偶爾會看到一些開發者僅僅因為有不好的感覺而否決一些東西，他們認為這些變更需要更多的測試，即使無法檢查出任何bug。人們總會發些牢騷，但是否決已經成立，而且變更不會進入發布（即使我不記得之后的測試是否發現了bug）。 ### 管理協作發布穩定化 如果你的項目選擇了一種變更表決系統，一定要確保設置投票和發布表決的物理機制盡可能的便利。盡管有大量開源電子投票軟件，在實踐中最簡單的方式還是在發布分支上設置一個叫做`STATUS`、`VOTES`或諸如此類的文本文件。這個文件列出所有的變更提議—任何開發者可以提出包含某個變更的提議—之后就是同意和反對它的表決，以及注釋或評論。 （提出一個變更并不意味著一定要為此投票，盡管兩者經常一起出現。）這個文件中任意一個條目的內容類似這個： ~~~ * r2401 (issue #49) Prevent client/server handshake from happening twice. Justification: Avoids extra network turnaround; small change and easy to review. Notes: This was discussed in http://.../mailing-lists/message-7777.html and other messages in that thread. Votes: +1: jsmith, kimf -1: tmartin (breaks compatibility with some pre-1.0 servers; admittedly, those servers are buggy, but why be incompatible if we don't have to?) ~~~ 在這個情況下，該變更得到了兩個贊成票，但是被tmartin否決，他在附加說明中給出了原因。該條目的詳細格式并不重要；你的項目如何設置都可以—或許tmartin的解釋應該出現在“Notes:”部分，也許變更描述也應該有一個”Description: “頭來匹配其他小節。重要的是需要評估這個變更的所有信息都是觸手可及的，進行投票的機制也是盡可能的保持輕量級。提議的變更直接用版本庫中的修訂號碼引用（如果是單個修訂可能是r2401，當然提議的變更也可能由多個修訂組成）。修訂可以是引用在主干上的變更；而如果變更就發生在發布分支，可能沒必要再表決了。如果你的版本控制系統沒有引用某個變更的明確語法，則項目需要建立一個。為了表決的可操作性，每個需要考慮的變更必須是明確可標識的。 這些提議和表決可以保證變更可以干凈的進入發布分支，也就是不會發生沖突（見[*沖突（conflict）*](#)）。如果有沖突，則該條目應當包含指向一個可以使變更變干凈的補丁，或者是包含已修正變更的臨時分支，例如： ~~~ * r13222, r13223, r13232 Rewrite libsvn_fs_fs's auto-merge algorithm Justification: unacceptable performance (>50 minutes for a small commit) in a repository with 300,000 revisions Branch: 1.1.x-r13222@13517 Votes: +1: epg, ghudson ~~~ 這個例子取自真實的生活；來自Subversion 1.1.4發布過程的`STATUS`文件。請注意，它是如何使用原始的修訂版本作為變更的標準描述方式，即使有一個分支已經有了修正沖突后的變更版本（為了更簡單的將一定會被通過的變更合并到發布版本，分支也將三個trunk的修訂版本合并為一個r13517）。這里還是提供了原始的修訂版本，作為最早的可以檢查的實體，因為他們都提供了原始的日志信息。臨時分支不會有那些日志信息，為了避免信息的復制（[Chapter?3, *技術基礎設施*](# "Chapter?3.?技術基礎設施")的[the section called “信息單一性”](# "信息單一性")），分支上r13517的日志信息僅僅是“調整r13222、r13223和r13232回到分支1.1.x。”關于變更的所有其他信息都可以跟蹤原始的修訂版本得到。 ### 發布經理 將已確認變更合并到發布分支的實際過程（見[*合并（又名搬運）（merge, a.k.a. port）*](#)）可以由任何開發者執行。不必有一個人專門負責合并變更；如果變更很多，最好能有人分擔工作。 然而，盡管表決和合并都以非集中的樣式出現，在實踐中通常會有一到兩個人掌控著發布過程。這個角色有時被正式的稱作*發布經理*，但是與擁有最終決定權的發布所有者（見本章前面的[the section called “發布所有者獨裁”](# "發布所有者獨裁")）有很大的區別。發布經理跟蹤當前有多少正在考慮的變更，有多少已經確認，有多少可能會被確認等等。如果他們感到重要的變更未能獲得足夠的關注，或者可能因為缺少投票而無法進入發布，他們會有禮貌的提醒其他開發者檢查并投票。當一組變更經過確認，這些人會自己去將它們合并到發布分支；如果有其他人愿意自己完成這個任務也沒有問題，只要所有人都理解如果他們沒有明確的聲明要自己做，這便不是強制要做的工作。當要將發布公布于眾時（本章后面的[the section called “測試和發布”](# "測試和發布")），發布經理將會完成最終發布包的創建，收集數字簽名，上傳發布包并作出公告。