在距离6.2-RELEASE发布还有大约一个月的时候，FreeBSD的developers邮件列表中开始了关于RELENG_7的讨论。出于对邮件列表相关规定的尊重，我不便公开这些讨论的内容，只说说一些我自己的想法。

在一个有数百人参加的开源项目中，如何保持良好的发行版本品质，同时又不伤害人们的参与热情和新功能的开发进度？

这是一个很明显的问题。对于用户来说，他们最关心的是稳定性和性能。一般说来，用户通常会对操作系统进行裁剪，以便适应他们的需要。然而，并不是所有的变动都能够有效地局部化或模块化，许多变动可能是涉及面非常广的，而另一些变动则可能涉及大量用户，或属于操作系统中「不可或缺」的部分。

许多FreeBSD的开发人员是利用业余时间进行开发活动的。多分支开发对于开发人员来说是一件很头疼的事情。许多开发人员可能没有时间和精力去维护多个分支(搭建测试环境等等都是相当耗时的工作；此外，为了维持ABI/API稳定，还需要编写一些额外的代码)，因此，多数开发人员会希望只有1个STABLE分支。

据我所知，FreeBSD是所有开源项目中对分支的运用最为「彻底」的一个。从CURRENT到STABLE到Release Engineering到发布，再到后期维护，有一系列完整的流程和开发常识支持。

不过目前这个流程也存在一些问题。从开发人员的观点看，我们希望在时间精力允许的前提下更快更多地发行release版本；而从用户的观点看，他们并不希望过快地发行新版本——变动可能引入问题，等等。因此，在5-STABLE到6-STABLE的转换过程中，许多人提出了我们应制定以时间为准绳的发布计划，并停止发布「新技术release」。

从用户的观点看，这样做是很有道理的。持续可用的平稳升级，对于用户与开发团队的良性互动十分重要。另一方面，FreeBSD的三个以时间为计划依据的版本系列——2.x、4.x和6.x版本，较之3.x和5.x版本来说，都要更为成功。

不过这样一来也会带来一些问题。新功能总要有人去做「小白鼠」。多数src committer，包括一些ports和doc committer都会使用-CURRENT作为桌面系统，以便在用户之前发现新版本中引入的问题；很明显，仅仅开发人员去跑测试是不够的。操作系统不是一个计算1+1=2的应用程序，FreeBSD仅内核部分的代码就超过300万行，由于手中缺少必要的硬件、偶然的疏忽或考虑不周等等，都可能使某些变动成为「按下葫芦浮起瓢」的事故。

自行编译和运行-CURRENT是一件十分辛苦的工作，对于不了解操作系统开发和内部运行机制的用户来说更是如此。然而，我们有很多十分热情的用户，他们希望能够帮助我们进行一些这方面的工作。为此，目前每个月re@都会发布一版新的snapshot来给大家试用。

那么，话说回来，为什么会有人提议尽早划出RELENG_7呢？

主要的好处是，这样一来，-CURRENT又回归到一个可以在上面增加还不算很靠谱的代码的地方了。与此同时，-STABLE分支则可以专注于可靠性的改良。

我个人不太赞成提前7个月划RELENG_7。但明年2、3月份也许是一个比较好的时机。