# 發布和日常開發 維護同時的平行發布包含了如何完成日常開發的暗示。特別是應該遵守每次提交只包含一個單獨邏輯變更的鐵律，絕不要在一次提交中混雜不相關的變更。如果一次提交的變更太大，或具有破壞性，可以分為N此提交，每次提交都是一個整體變更的分區子集，而且不包含與整體變更無關的內容。 這里是一個未經慎重考慮進行提交的例子： ~~~ ------------------------------------------------------------------------ r6228 | jrandom | 2004-06-30 22:13:07 -0500 (Wed, 30 Jun 2004) | 8 lines Fix Issue #1729: Make indexing gracefully warn the user when a file is changing as it is being indexed. * ui/repl.py (ChangingFile): New exception class. (DoIndex): Handle new exception. * indexer/index.py (FollowStream): Raise new exception if file changes during indexing. (BuildDir): Unrelatedly, remove some obsolete comments, reformat some code, and fix the error check when creating a directory. Other unrelated cleanups: * www/index.html: Fix some typos, set next release date. ------------------------------------------------------------------------ ~~~ 當某人需要將`BuildDir`錯誤檢查修正搬運到維護即將到來維護發布分支時，這種問題立刻變得非常明顯。搬運者不希望任何其他的變更—例如，#1729問題的修正未能通過維護分支的確認，而且`index.html`的修改變得毫無關系。但是她不能僅僅通過版本控制工具的合并功能只獲取`BuildDir`的變更，因為版本控制系統被告知該變更在邏輯上由所有其他不相關的事務組成。實際上，在合并之前這個問題也十分明顯。僅僅為表決列出變更會有許多問題：不僅僅要提供修訂版本號碼，提議者也必須提供特別的補丁或變更分支，才能將提議的部分分離出來。對于其他人來說還要承受許多任務，僅僅因為最初的提交者未能按照邏輯把事情分組。 實際上，這個提交應該分為*四*次獨立的提交：一個用于修正#1729，另一個刪除`BuildDir`中廢棄的注釋，并重新格式化代碼，還有一個修正`BuildDir`中的錯誤檢查，最后要修改`index.html`。其中第三個提交應該是為維護發布分支所做的提議。 當然，發布穩定不僅僅是要求每次提交僅包含一個邏輯變更的唯一原因從心理學上講，語義上統一的提交更利于檢查，更利于在必要時回退（在某些版本控制系統，回退只是一種特殊的合并）。這種每個人預先遵守的紀律可以避免項目之后的頭痛。 ### 計劃發布 與私有項目相比，開源項目在發布計劃上有歷史上的區別。私有項目通常有嚴格的最后期限。有時是因為已經向客戶許諾在規定時間完成升級，可能因為新發布需要配合其他市場目標的投入，也可能是因為風險投資希望在進一步投入前看到些結果。而對于自由軟件項目，現階段主要是由業余開發者以最字面意義的方式激勵著：因為喜愛，所以編碼。在所有的特性完畢之前，沒有人覺得需要裝運。并不是所有人的工作都在開發線上。 現今，許多開源項目由公司資助，越來越受到公司文化中的最后期限影響。無論如何這也是一件好事，但是會導致有工資的私有開發者與志愿貢獻時間的沖突。這些沖突通常會圍繞何時以及如何計劃發布等問題發生。處于壓力之下的有工資開發者很自然會希望選擇一個發布發生的日期，并讓每個人的活動投入到這個發布線。但是志愿者有自己的日程—或許是他們希望完成的特性，或一些希望進行的測試—他們希望發布能等待這些工作完成。 當然對于此類問題，除了討論和妥協沒有普通的解決方案。但是通過將發布中某個提議的*出現*與其完成的日期解耦，你可以最小化所導致阻力的頻率和程度。也就是將討論主題導向到項目在近期，以及中期將要作出的發布，以及其中包含的哪些特性，而不必一開始就確定所有關于日期的事情，除了粗略的一些猜測。[[23](#)]。通過盡早明確特性集合，你減少了針對任何單個發布討論的復雜度，因而改進了可預測性。這也創建了一種慣性偏見，針對通過添加特性或其他復雜度的提議以擴展發布定義的人。如果發布的內容定義良好，則提議者需要承擔證明該擴展的負擔，即使發布的日期還沒有設定。 在Thomas Jefferson的多卷傳記*Jefferson and His Time*中，Dumas Malone講了一個故事，Jefferson如何處理決定弗吉尼亞大學未來組織結構的第一次會議。大學首先來自Jefferson的一個構想，但是（不僅僅是在開源項目，其他領域也屢見不鮮）有許多其他參與者，都有自己的興趣和日程。當他們召集在一起舉行第一次會議時，Jefferson確保展示了精心準備的架構圖，以及希望從歐洲引入的特定教職員工的姓名。房間中所有其他人都沒有任何準備；這個團隊從本質上就需要服從Jefferson的遠見，而這個大學最終幾乎按照他的計劃建立。事實上整個建設遠超預算，他的許多想法出于很多原因，最終未能得到解決，但那都是Jefferson一開始就了解，并預計到會發生的事情。他的目的是策略性的：通過在會議上展示非常確實的東西，讓其他所有人僅僅需要履行修改提議的角色，所以項目整體的形狀，以及隨之而來的日程也可以和他的預期大體一致。 對于開源軟件項目，沒有一個單獨的“會議”，而是一系列由問題跟蹤系統代表的小建議。但是如果你在項目開始時有一些信譽，而且根據宣稱的整體計劃將許多特性、改進和bugs賦予到問題跟蹤系統中的目標發布版本，人們會和你走到一起。一旦你根據自己的需要確立了一些事情，關于實際發布*日期*的對話將會變得非常平滑。 另一個很重要的，不要把任何決定當作是天經地義的。對于未來特定發布的某個問題所關聯的注釋中，邀請討論、異議并盡可能真誠的希望被說服。不要為了練習控制而練習控制：其他人越是深入的參與到發布計劃過程（見[Chapter?8, *管理志愿者*](# "Chapter?8.?管理志愿者")的[the section called “像分擔技術任務一樣分擔管理任務”](# "像分擔技術任務一樣分擔管理任務")），越是容易說服其他人分享你在這個問題上本屬于你的特權。 另一個降低項目發布計劃緊張程度的方法是提高發布的頻率。當發布之間的時間很長時，每次發布在每個人心目中的地位也被放大；如果他們的代碼未能進入，他們會感覺到更多的壓力，因為他們知道下一次機會要等待很久。根據發布過程的重要程度，以及項目的本性，發布的間隔可以在3個月到6個月之間，盡管如果有需求時，維護線可以讓微小發布更快一點。 [[23](#)] 作為另外一個選擇，你或許希望閱讀Martin Michlmayr博士的論文*QualityImprovement in Volunteer Free and Open Source Software Projects:Exploring the Impact of Release Management*（[http://www.cyrius.com/publications/michlmayr-phd.html](http://www.cyrius.com/publications/michlmayr-phd.html)）。它使用的是基于時間的發布過程，而不是基于特性的大型自由軟件項目。Michlmayr也在Google提供了一個該主題的演講，可以通過Google Video的[http://video.google.com/videoplay?docid=-5503858974016723264](http://video.google.com/videoplay?docid=-5503858974016723264)觀看。