在免费软件项目的版本管理中，有一种模式是我们时时拿出来讨论的：为了实现影响巨大的大修，开发者使用了开发分支（development branch），将大部分开发者的着重点转移到开发代码线，但同时，大部分用户还会留在原本的稳定分支版本上。
这样一来，由于缺少用户的测试，开发代码线难以快速更新出稳定版本，而且由于用户仍在使用旧有的稳定版本，开发者需要将新功能移植回去，这些浪费的时间本可以用来稳定开发分支，结果可能会发展成死循环。因此人们提出质疑：一开始就分出这样的大型分支是否有问题，甚至使用新分支这个想法本身是否合适？
让一切更为复杂的是：经常在大多数据库和应用接入前，开发者就会宣称开发代码线已经“稳定”。这种案例至少有三起：
- 第一次是在Linux 2.4/2.5时代，Wiki上有相关描述：
Linux 2.6之前，有一个稳定的分支（2.4），只添加了少量安全的更改；还有一个不稳定的分支（2.5），其中进行了较大的变更；两个分支版本的维护者都是以Linus Torvalds为首的同一批人。
也就是说，尽管必须等到2.5版本的新功能移植过来，但用户始终能用到最新修复了安全性问题与bug，且经过充分测试的2.4版本。
这种做法的缺陷在于：“稳定”的内核严重滞后，不但不受最新的硬件支持，还缺少所需功能。Linux 2.5.x的内核更新到后期时，一些维护者尝试将自己的变更移植到稳定的2.4.x版本中，导致2.4.x引入了一些bug。最终，2.5分支在宣布稳定后，更名为2.6版本。不过，内核的开发者决定不再开启新的分支，也就是按照习俗应当被命名为2.7.x系列的不稳定分支，而是直接对2.6版本进行大修大改。因此，2.6.x系列的更新速度要快于2.4.x系列，不过会比2.5.x系列慢一些。这样一来，我们达到了预期的效果——添加新功能的速度更快，而且因为是分次小批量加入的，也能对新代码进行更多的测试。
-
在Ruby社区，2007年的时候Ruby的稳定版是Ruby 1.8.6，而2007年12月26日发布的Ruby 1.9.0是非稳定版，作为Ruby主分支的复制版本，大多数开发者将精力投入了1.9.x版本。在2009年1月31日，1.9.x系列的Ruby 1.9.1发布，并宣布为该系列的稳定版。但由于Ruby 1.9的变化太大，很多库无法兼容1.9.x系列，导致用户仍在使用Ruby 1.8版本。2011年的时候，Debian在Squeeze版本中对两个版本的Ruby均提供支持，不过直到2012年才将默认支持对象修改为1.9系列。
-
最后再看看Python社区，与Ruby 1.9系列的情况类似，Python 3.0也是在2008年12月发布的，Debian在Squeeze（3.1）、Wheezy（3.2）还有Jessie（3.4）中应用了3.x版本，但“python”命令仍指向2.7版本，而且似乎并没有变更到3.x系列的计划，使得python 3.x本质上成了另一种语言。
结论：
根据实践经验：尽早、频繁进行分支，并定期修复一定量的问题是一个不错的方案。
这样做的代价是：让用户时常面对程序出现的问题，同时开发者需要花费更多时间寻找方案，来减少这些问题带来的不利影响。不过，随着自动化测试和持续集成的大量普及，我们也能更容易地衡量变更的代价。分销机制也很有帮助，可以让开发者更快了解对上游项目进行潜在巨大变更后获得的反馈信息；而且，由于在同一个项目中包含两个不兼容的分支版本一般来说是不合适的，一般我们也不会这样做。
原文链接： The Linux 2.5, Ruby 1.9 and Python 3 release management anti-pattern（编译/孙薇 责编/钱曙光）