# Chapter 7. 打包、发布和日常开发 本章关于自由软件项目如何打包和发布软件，以及如何让整个开发模式的组织围绕这个目标。 开源项目和私有项目的主要区别是缺乏对开发团队的中央管理。当准备新版本时，这个区别尤其明显：一个公司可以让整个开发团队集中精力在即将发生的版本上，而将新特性开发和不重要的bug修正放在一边。志愿团队不会如此整齐划一。人们因为各种各样的原因为项目工作，总有些人会对发布版本不感兴趣，会希望在发布时继续常规的开发工作。因为开发不会结束，开源的发布流程很容易变长，但不会如商业发布流程那样分裂。这就像修理高速路。有两种修理方法：你可以将其完全关闭，这样船员们可以全力投入，直到问题被解决，或者你可以在多个小道上同时工作，而让其他人可以自由通行。第一种方法*对修理船员非常有效率*，但对于其他人来说—完成任务前道路被完全关闭。第二种方法，修理船员（现在他们需要与较少）会需要更长的时间，但至少道路保持可用，尽管不能完全畅通。 开源项目通常会使用第二种方法。实际上，对于同时拥有多条版本线的成熟软件，项目一直处于修理小路的状态。总会有些小道会被关闭；一直存在的但是较低级别的不便能够被整个开发团队容忍，所以才能够有规律的计划发布版本。 这个模型不仅仅能用于版本发布。其原理是并行任务并不是互相依赖的—这并不是只存在于开源项目的原理，但开源项目使用了自己的方法实现了它。他们不能承受对修路工队员或常规交通的过度打扰，同样也不能承受让人们只是站在黄线以外，等待交通疏导。因而，他们会向平缓的、稳定管理负担的过程发展，而不会是充满更多的山谷和高峰。志愿者通常会希望工作中只有一些虽然持续但不太严重的不便；提供些许他们可预测性会让他们可以自由的安排自己的日程，无需担心在项目中发生冲突。但是，如果项目主日程中有些活动会排除其他活动，就会导致很多开发者停止很长时间—不仅非常没有效率，也非常无聊，因而会很危险，因为无聊的开发者会很快变成前开发者。 版本发布工作实际上是并行开发中最容易被注意到的非开发任务，所以下面章节中描述的方法主要针对如何允许发布。然而，也有其他的并行任务，例如翻译和国际化、在整个代码的基础上逐渐扩大API变更等。