从Alpha到RC的命名规则与最佳实践
目录导读
- 为什么需要预发布版本标识？
- 常见预发布版本标识体系
- 1 SemVer语义化版本中的预发布标签
- 2 常见后缀词含义（Alpha、Beta、RC）
- 预发布版本标识的实际应用
- 1 版本号格式与示例
- 2 版本递增规则
- 不同开源项目的标识实践对比
- 1 Kubernetes
- 2 Node.js
- 3 Python
- 预发布版本标识的常见问题与问答
- 最佳实践建议
为什么需要预发布版本标识？
在开源项目中,预发布版本（Pre-release Version） 是指尚未达到正式发布标准，但需要提供给社区测试、反馈或早期采用的版本，标识这些版本的核心目的是明确告知用户该版本的稳定性和风险等级，避免用户误将不稳定的版本用于生产环境。
根据semver.org（语义化版本规范）的定义，预发布版本通过在版本号后添加连字符和标识符来区分。0.0-alpha.1，这种标识不仅是对开发进度的标记，更是对用户预期管理的工具。
关键问题：如果所有版本都叫“最新版”，用户如何区分哪个是稳定版、哪个是测试版？答案就在标识体系中。
常见预发布版本标识体系
1 SemVer语义化版本中的预发布标签
语义化版本（Semantic Versioning，简称SemVer）是目前最广泛采用的版本规范，其核心结构为：
主版本号.次版本号.修订号-预发布标签+构建元数据- 主版本号：不兼容的API修改
- 次版本号：向下兼容的功能新增
- 修订号：向下兼容的问题修正
- 预发布标签：用连字符连接，
-alpha.1,-beta.2,-rc.3 - 构建元数据：用加号连接，
+build.20231001
注意：预发布版本的优先级低于对应的正式版本。0.0-alpha < 0.0。
2 常见后缀词含义
| 标识符 | 全称 | 含义 | 稳定性等级 | 典型场景 |
|---|---|---|---|---|
alpha |
Alpha | 内部测试版 | 极低 | 新功能原型验证，可能有严重Bug |
beta |
Beta | 公测版 | 低 | 社区测试，功能基本完成，但需修复已知问题 |
rc |
Release Candidate | 发布候选版 | 中 | 功能冻结，仅修复关键Bug，接近正式版 |
dev |
Development | 开发版 | 极低 | 每日构建或持续集成版本 |
snapshot |
Snapshot | 快照版 | 极低 | 用于依赖管理的临时版本 |
现实案例：
- Vue.js 2.7 发布前曾经历
7.0-alpha.1→7.0-beta.1→7.0-rc.1→7.0 - Node.js 18 的发布周期：
0.0-nightly20220101→0.0-rc.1→0.0
预发布版本标识的实际应用
1 版本号格式与示例
在实际项目中,常见的格式演变遵循以下模式：
主版本号.次版本号.修订号-标签.序号示例：
0.0-alpha.1→ 第一个Alpha测试版0.0-alpha.2→ 第二个Alpha测试版（修复了alpha.1的问题）0.0-beta.1→ 第一个Beta测试版0.0-rc.1→ 第一个发布候选版0.0-rc.2→ 第二个发布候选版（修复了rc.1的严重问题）0.0→ 正式版
进阶格式：有时会嵌套使用，-alpha.1.2，但官方SemVer推荐使用点分隔的数值标识。
2 版本递增规则
SemVer明确规定了预发布版本的比较规则：
- 字段按点分隔逐段比较
- 数字字段按数值比较,字母字段按ASCII比较
- 更多字段的版本 > 较少字段的版本（当前面字段相等时）
0.0-alpha < 0.0-alpha.1 < 0.0-alpha.beta < 0.0-beta < 0.0-beta.2 < 0.0-beta.11 < 0.0-rc.1 < 0.0
注意：rc > beta 是因为 r > b 的ASCII码？不，这里是非数字字段按字母比较，但实际比较中应避免依赖字母顺序，而是使用数字序号。-beta.1 和 -rc.1，通常规范建议用数字序号明确比较关系。
不同开源项目的标识实践对比
1 Kubernetes
Kubernetes 使用独特的标识方式：v1.27.0-alpha.1, v1.27.0-rc.1，但注意他们在版本号前加 v，这是社区习惯。
K8s 还会在预发布版本后附加构建日期或git提交哈希，v1.27.0-rc.1+123abc。
2 Node.js
Node.js 的发布周期极其规范：
- 当前版本（Current）：偶数主版本号，如
x - LTS版本：偶数主版本号，如
12.0（LTS表示长期支持） - 预发布版本：
0.0-nightly20220101（nightly每日构建版）
3 Python
Python 使用类似 SemVer 但略有不同：
11.0a1（Alpha 1）11.0b2（Beta 2）11.0rc3（Release Candidate 3）11.0（正式版）
重要区别：Python 使用 a1 而非 alpha.1，且字母位置不同。
常见问题问答
Q1: 预发布版本需要遵循语义化版本吗？
A: 是的，预发布版本必须在正式版本号基础上附加标签，且预发布版本的优先级低于正式版本。0.0-rc.1 < 0.0，但 0.0-rc.5 可能大于 0.0-rc.1。
Q2: 如果项目只用 beta 不用 alpha 可以吗？
A: 可以，并非所有项目都需要完整的 Alpha → Beta → RC 链条，很多项目直接从开发版跳到 RC，但建议保持一致性，并在项目文档中明确说明。
Q3: 预发布版本号中的序号可以从 0 开始吗？
A: 可以。-alpha.0, -beta.0，常见做法是从1开始，但规范并未禁止从0开始。
Q4: 如何判断一个预发布版本是否可安全试用？ A: 按稳定性排序：Alpha < Beta < RC < 正式版，RC版本的代码已经冻结，仅修复关键Bug，参与测试风险较低，Alpha版本可能包含未完全实现的功能或明显Bug。
Q5: 版本号里可以同时有预发布标签和构建元数据吗？
A: 可以。0.0-alpha.1+20130313144700，构建元数据（加号后）不影响版本优先级比较。
预发布版本标识的常见问题与问答
1 如果版本号中包含日期，如何处理？
10.01 这样的日期版本号，这属于另一种版本标识体系（日期版本），虽然不遵循SemVer，但在某些项目中也被使用，但建议：如果使用日期版本，也应附加预发布标签，10.01-beta。
2 为什么有些项目用 dev 而不用 alpha？
dev表示持续集成生成的版本，可能每天一个。alpha表示一个经过人工选择的测试版本，通常质量略高于日常构建。- Apache Maven 使用
0.0-SNAPSHOT表示开发版快照。
3 如何对待用户对预发布版本的反馈？
最佳实践：在预发布版本的README或发布日志中明确标注：
- 该版本的风险等级
- 已知的Breaking Changes
- 反馈渠道和预期回复时间
Version 2.0.0-beta.1
注意：这是预发布版本，不推荐用于生产环境，已知问题包括：X功能未完成、Y bug未修复，欢迎在GitHub Issues提交反馈。
4 如果正式版本发布后发现严重Bug，需要回滚吗？
不应回滚,应发布一个补丁版本（修订号递增），例如从 0.0 回退到 9.1 是不推荐的，正确做法是发布 0.1 修复问题，但如果是预发布版本发现严重Bug，可直接递增预发布序号发布新版，0.0-rc.2 修复后改为 0.0-rc.3。
最佳实践建议
- 遵循SemVer规范：这是被绝大多数社区接受的标准，降低沟通成本。
- 保持一致性：整个项目中使用相同的标签体系，如全部使用小写字母、数字序号。
- 文档透明：在项目的README或CONTRIBUTING.md中解释版本标识规则。
- 自动化生成：使用CI/CD工具自动生成预发布版本号，避免手动错误。
- 尊重版本比较规则：确保包管理工具（如npm, pip, gem）能正确比较预发布版本优先级。
- 慎重使用
-dev后缀：因为很多工具将-dev默认为“开发版”，可能导致用户安装错误的版本。 - 避免使用非标准后缀：如
-unstable,-test,-draft，除非你能确保整个工具链都能正确解析。
预发布版本标识是开源项目质量管理和用户沟通的重要工具,合理的标识体系能帮助用户快速判断是否应该升级或试用，同时建立项目团队的专业形象。
本文参考了语义化版本规范（semver.org）、Kubernetes、Node.js、Python等主流开源项目的版本管理实践，以及相关技术社区的讨论，如需深入了解，请访问域名 semver.org 获取完整规范。
