发布候选版本（RC）：含义、版本号写法与运作方法
阅读约 1 分钟
发布候选版本（RC）是团队认为已经可以发布的一个构建。它功能齐全，已通过计划中的测试，并且除非有人发现严重到足以阻塞发布的缺陷，否则它会原封不动地成为正式版。这个标签是对该构建的一项承诺：不再加新功能，只修复阻塞问题。如果需要修复，团队就切出一个新的候选版本，重新开始计时。
| 阶段 | 功能 | 受众 | 预期状态 |
|---|---|---|---|
| Alpha | 仍在添加 | 内部团队 | 不完整，已知缺陷很多 |
| Beta | 已完成或接近完成 | 志愿者和选定的客户 | 可用，预计会有缺陷 |
| 发布候选版本 | 已冻结 | 测试人员和早期使用者 | 认为已就绪，只修阻塞问题 |
| 正式发布（GA） | 已冻结 | 所有人 | 与最后一个 RC 是同一个构建 |
软件中的发布候选版本是什么？
它是正式发布（GA）之前的最后一个预发布阶段。其思路是，这个构建是最终版本的候选，发布时是把同一个构建提升为正式版，而不是另做一个新的。维基百科关于软件发布生命周期的文章描述了同样的 alpha、beta、发布候选和正式发布的顺序，这些术语在开源项目和软件厂商之间被广泛理解。
beta 和发布候选版本有什么区别？
beta 仍然允许变动。功能可以调整，接口可以变化，目标是弄清缺了什么、错在哪里。发布候选版本已经停止了这类改动，目标是确认没有任何问题阻塞发布。实际的检验方法，是看团队怎么处理一份缺陷报告。在 beta 阶段，一份报告可能带来设计上的改动。在 RC 阶段，只有当缺陷会阻塞发布时，报告才会带来修复，其余的一律排进下一个版本。
如何给发布候选版本编版本号？
在你即将发布的版本号上加一个预发布后缀。按语义化版本控制的规定，连字符加上用点分隔的标识符表示预发布，所以 2.4.0 的第一个候选版本是 2.4.0-rc.1，下一个是 2.4.0-rc.2，正式版就是不带后缀的 2.4.0。
优先级按规范来：2.4.0-rc.1 排在 2.4.0-rc.2 之前，任何预发布版本都排在正式版之前。由于标识符是逐个比较的，数字按数值比较，所以 rc.10 排在 rc.9 之后。alpha、beta 和 rc 这几个名字按字母顺序排序，恰好也是正确的先后次序，这也是团队采用它们的原因之一。每个候选版本都要在 git 中打上标签，做法见 git 标签与发布，这样确切的提交就有了记录。
发布候选版本的退出标准是什么？
在切出第一个 RC 之前就把它们写下来。一套可行的标准如下：
- 自动化测试套件在所构建的那个确切提交上通过。
- 从上一个版本升级的路径，已用接近真实的数据测试过。
- 已知问题都已分级处理，没有一个被评为阻塞。
- 性能和错误率与上一个版本相比，差异在约定的范围内。
- 发布说明已经起草，并对照最终的变更清单评审过。
- 存在回滚路径，并且有人读过它。
当某个候选版本满足每一条时，这个候选版本就是正式版。只要有任何一条不满足，修复就会产生一个新的候选版本，检查也要重新开始。这套流程的七步版本，以及每一步的负责人，见发布管理流程。
RC 通过之后，该怎么处理这个构建？
提升同一个制品。不要从标签重新构建，因为重新构建可能引入不同的依赖或编译产物，而你做过的测试针对的是原来的构建。很多团队通过重新打标签或重新指向仓库中的标签，来给候选版本改名，这样被测试过的字节，就是用户下载到的字节。
对于软件包，要把候选版本发布到单独的渠道，这样普通用户就不会意外收到它们。使用 npm 时，npm publish --tag rc 会让默认的 latest 标签保持原样，只有指定 @rc 的人才能拿到候选版本。容器镜像和移动应用构建也有同样的思路，只是名称不同：预发布标签、分阶段推出，或者类似 TestFlight 的测试轨道。
如何为发布候选版本撰写发布说明？
从第一个 RC 就开始写发布说明，并让它与候选版本保持同步。测试人员需要知道改了什么、该检查什么、已知哪里有问题，而且提早起草能找出到最后没人记得的条目。把页面或 GitHub 发布标记为预发布，这样没人会把它误当成正式版，等正式发布时，再把写好的文字移到 GA 发布上。版式和内容见软件发布说明，GitHub 一侧见 GitHub 发布说明。
SaaS 团队需要发布候选版本吗？
持续部署的团队很少需要，因为生产环境的部署本身就是测试，而且由功能开关控制谁能看到变更。当用户自行安装软件、无法通过一次部署回滚时，发布候选版本才有用武之地：库、桌面和移动应用、自托管产品，以及客户端长期存在的 API。对于逐步放出变更的托管产品，对应的做法是分阶段推出，feature flag 发布说明这篇文章从沟通的角度讲了这件事。
FAQ
软件中的 RC 是什么意思? RC 是 release candidate 的缩写，即发布候选版本。它是团队打算作为最终版本发布的构建，除非测试发现了阻塞缺陷。它排在 alpha 和 beta 阶段之后，正式发布之前。
发布候选版本稳定到可以用于生产环境吗? 在预发布环境或有限的生产环境中测试，通常可以，但它带有正式版没有的风险，因为测试可能还没有完成。把它当作仍在试用期的生产级代码来对待。
一次发布应该有多少个发布候选版本? 需要几个就有几个，大多数发布需要一到三个。连续出现很多候选版本，通常意味着冻结宣布得太早，或者测试覆盖让问题发现得太晚。
发布候选版本可以不做任何改动就成为正式版吗? 可以，这正是预期的结果。正式版应当与最后一个候选版本是同一个构建，只是改了名称或重新标记为 GA。
本文的技术内容未经独立审核。如有错误，请告诉我们，我们会更正。