先看三个数字。
648 天——Subversion 1.5.0 距离上一个 feature release 1.4.0 的间隔。此前几个版本的间隔分别是 219、234、223、254 天，基本稳定在七到八个月。1.5 直接翻倍。
11 个 RC——为了发出 1.5.0，release manager 一共做了 11 个 release candidate。此前版本的 RC 数量是 1、4、4、7、5。
5 个未公开——这 11 个 RC 里，有 5 个连正式发布都没有，因为内部验证就没过。
这些数字来自 Hyrum K. Wright 和 Dewayne E. Perry 在 2009 年 ICSE FLOSS Workshop 上发表的论文 Subversion 1.5: A Case Study in Open Source Release Mismanagement。Wright 本人就是 1.5.0 的 release manager，所以这不是旁观者复盘，而是当事人回头看自己怎么把船开进了暗礁。
它讲的是 2007–2008 年的 Subversion，但问题今天依然常见：一个“大 feature”，如何拖住整个版本。
一、Subversion 1.5 本来要做什么
Subversion 1.4 在 2006 年 9 月发布时，已经基本完成了“取代 CVS”的初始使命。社区开始推进更高级的功能，其中最重要的一个是 merge tracking：自动追踪 branch 之间的合并记录。
在此之前，SVN 用户做 merge 时，要自己记哪些 change 已经合并到哪个 branch。繁琐、易错，企业用户抱怨已久。把这件事自动化，自然成了 1.5.0 的招牌 feature。
问题也从这里开始。
二、事情怎么失控
merge tracking 在一个 feature branch 上开发。半年过去，branch 越来越复杂，却迟迟没有 merge 回 trunk。
2007 年 3 月，已经有开发者提议：先发一个不带 merge tracking 的中间 feature release，把已经完成的东西放出去。 社区否决了这个提议，理由是 merge tracking 快做完了，中间 release 反而拖时间。
后来的事证明，它并没有“快做完”。
这个 feature 越做越复杂，复杂到只有少数核心开发者真正能动。新人想帮忙也插不上手。到发布前期，能发现问题的人远多于能修问题的人。设计上有缺陷，只能靠 workaround 兜着；defect rate 一直降不下来，但内外部压力又不断催促发版。
2008 年 1 月底，1.5 的 release branch 终于切出来。接下来是五个月的拉扯：
• 2 月底出了两个 alpha——这是 SVN 史上第一次使用 alpha，因为团队自己也不知道该怎么命名当前状态；
• 社区对下一个 pre-release 叫什么产生分歧：一派想直接进 RC，启动 4 周 soak；另一派认为“这状态配不上 RC”，最后折中出了一个 beta；
• 4 月初，第一个真正的 RC 才发布，距切 branch 已经超过两个月；
• 4 月底 RC4 才启动 soak，前三个 RC 都没正式公开；
• soak 期间和之后，下游 distributor、API 消费者才开始认真测试，又挖出一批 bug，导致 RC 连续追加；
• 6 月 19 日，1.5.0 带着 known bugs 发布。社区接受了现实：再拖只会更糟，剩下的问题留给 patch release。
事后看，1.5.0 的那些 bug 没有一个是真正的 showstopper，后来都在 patch release 里修掉了。
三、四个教训
教训一：不要用一个 feature 定义整个 release
社区把 1.5.0 定义成“加入 merge tracking 的版本”。从那一刻起，1.5.0 就和一个复杂度不可控的 feature 绑死了。merge tracking 一天不完成，1.5.0 就一天发不出去；期间其他已经完成的功能，也只能一起等。
替代方案本来存在：盘点 trunk 上已经 ready 的内容，就以这些内容定义 1.5.0。merge tracking 没赶上，就放到 1.6。但社区在关键节点选择了等待。
Wright 的总结很直接：与其把 release 定义为某个 feature，不如把 feature 设计成可以独立于 release 演进的东西。
这件事会反过来影响架构。merge tracking 被当成一个必须整体交付的原子 feature，于是不能拆、不能并行、不能部分发布，测试面积越来越大，release cycle 也越来越长。
后来 Subversion 学到了这个教训。1.5 之后的两个大 feature——next-generation working copy 和 tree conflict resolution——都采用更模块化的方式实现，可以以“部分但仍有用”的状态发布。
教训二：不愿带 known bugs 发版，也可能是一种 bug
开发者不愿发布带 bug 的代码，这看起来是职业操守，但很多时候只是完美主义。
Wright 有句话很值得记住：
对绝大多数用户而言，“完美但还没发布的代码”等价于“不存在的代码”。
回头看，1.5.0 那些反复推迟发布的 bug，没有一个是真正的阻断问题，后来都通过 patch release 修掉了。但用户为此多等了近一年。他们要么继续忍受 1.4 的痛点，要么自己拉 trunk 编译。
发布判断不该是“这个版本是否完美”，而该是：这个版本对用户的净价值是否已经明显为正。
1.5.0 其实早就过了这个阈值，只是社区不愿承认。
教训三：流程不是为了出版本，而是为了让版本可解释
Subversion 有发布流程，写在 HACKING 指南里：alpha、beta、RC、soak、签名要求，都有规定。1.5 的问题不是没有流程，而是团队为了“先发点东西”，开始稀释流程的语义。
第一次使用 alpha 时，没人说清楚 alpha 和 RC 在 SVN 语境里的区别。后来 11 个 RC 里有 5 个没公开，RC 这个 label 也开始失真。
一旦每个阶段都需要临时解释“这次的 RC 不太一样”，流程就已经失效了。
更麻烦的是，下游也会根据这些 label 安排自己的节奏。SVN 的 distributor、API 消费者，直到看见“真的快发了”才认真测试。label 一旦失真，反馈节奏也会跟着失真。
教训不是“严格遵守旧流程”。SVN 原来的流程本来就不适合 merge tracking 这种体量的 feature。真正的教训是：当流程不适应现实时，应该改流程，而不是靠稀释 label 的语义来通融现状。
教训四：time-based release 的前提，是 feature 可以错过这班车
Wright 提倡 time-based release，并用了一个很好的比喻：公交站哲学。
如果一个 feature 赶不上这班车，下一班很快就来。所以不要为了任何单个 feature 扣留 release。
这对 SVN 这种依赖下游生态的项目尤其重要。distributor、IDE 集成方、企业部署团队，都需要可预期的发布节奏来安排自己的工作。1.5 这种无限期拖延，对整个生态都是噪音。
但 time-based release 不是银弹。临近 deadline 时，团队仍然要决定砍 feature、推迟日期，还是部分发布。真正能让 time-based release 运转起来的前提是：feature 本身可以被拆开，哪怕只发一部分，也仍然有价值。
这又回到了第一条。
事实上，1.5 之后 Subversion 的节奏明显恢复。1.5.x patch release 大约每六周一个；1.6 在 2009 年 2 月切 branch，3 月按计划发布。能拆 feature，time-based release 才真正可执行。
四、真正的问题不是 release，而是架构
把这四条放在一起看，会发现它们其实是一条链：
feature 是否可拆分，决定了能不能做 time-based release；能不能稳定发布，又决定了流程 label 是否还能可信；流程 label 是否可信，进一步影响团队是否敢带 known issues 发版。
反过来也成立：如果一个项目总是要求“大 feature 必须一次性交付完整形态”，那 release 迟早会被 feature 绑架，流程 label 会被反复稀释，完美主义也会变成拖延的借口。
这件事不只属于开源项目。任何平台或工具团队在做大 feature 时，都要面对同一个选择：把它设计成必须一次性交付的整体，还是设计成可以分阶段发布、独立演进的几个部分。
前者更像一个完整里程碑，也更容易讲故事。但代价会在别处出现：发布节奏、生态信任、团队士气，都会被慢慢消耗。
Subversion 1.5 的故事发生在 2008 年，但它真正讲的不是 release management，而是架构选择如何在下游变成 release 危机。
每次我们把一个版本命名成“那个会有 X 的版本”时，都该先停一下，问一句：
X 真的必须是原子的吗？
论文原文：Hyrum K. Wright, Dewayne E. Perry. Subversion 1.5: A Case Study in Open Source Release Mismanagement. ICSE 2009 FLOSS Workshop. PDF：https://www.hyrumwright.org/papers/floss2009.pdf
好文推荐：
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
