# Chapter?7.?打包、發布和日常開發 本章關于自由軟件項目如何打包和發布軟件，以及如何讓整個開發模式的組織圍繞這個目標。 開源項目和私有項目的主要區別是缺乏對開發團隊的中央管理。當準備新版本時，這個區別尤其明顯：一個公司可以讓整個開發團隊集中精力在即將發生的版本上，而將新特性開發和不重要的bug修正放在一邊。志愿團隊不會如此整齊劃一。人們因為各種各樣的原因為項目工作，總有些人會對發布版本不感興趣，會希望在發布時繼續常規的開發工作。因為開發不會結束，開源的發布流程很容易變長，但不會如商業發布流程那樣分裂。這就像修理高速路。有兩種修理方法：你可以將其完全關閉，這樣船員們可以全力投入，直到問題被解決，或者你可以在多個小道上同時工作，而讓其他人可以自由通行。第一種方法*對修理船員非常有效率*，但對于其他人來說—完成任務前道路被完全關閉。第二種方法，修理船員（現在他們需要與較少）會需要更長的時間，但至少道路保持可用，盡管不能完全暢通。 開源項目通常會使用第二種方法。實際上，對于同時擁有多條版本線的成熟軟件，項目一直處于修理小路的狀態。總會有些小道會被關閉；一直存在的但是較低級別的不便能夠被整個開發團隊容忍，所以才能夠有規律的計劃發布版本。 這個模型不僅僅能用于版本發布。其原理是并行任務并不是互相依賴的—這并不是只存在于開源項目的原理，但開源項目使用了自己的方法實現了它。他們不能承受對修路工隊員或常規交通的過度打擾，同樣也不能承受讓人們只是站在黃線以外，等待交通疏導。因而，他們會向平緩的、穩定管理負擔的過程發展，而不會是充滿更多的山谷和高峰。志愿者通常會希望工作中只有一些雖然持續但不太嚴重的不便；提供些許他們可預測性會讓他們可以自由的安排自己的日程，無需擔心在項目中發生沖突。但是，如果項目主日程中有些活動會排除其他活動，就會導致很多開發者停止很長時間—不僅非常沒有效率，也非常無聊，因而會很危險，因為無聊的開發者會很快變成前開發者。 版本發布工作實際上是并行開發中最容易被注意到的非開發任務，所以下面章節中描述的方法主要針對如何允許發布。然而，也有其他的并行任務，例如翻譯和國際化、在整個代碼的基礎上逐漸擴大API變更等。