3. 版本号规范:语义化版本控制(SemVer)详解

在制品管理与回滚体系中,版本号是唯一标识制品状态的“数字指纹”。语义化版本控制(Semantic Versioning,简称 SemVer)是目前业界最广泛采用的版本号规范,它通过 主版本号.次版本号.补丁号 的三段式结构,清晰传达每次变更的兼容性与影响范围。

3.1 SemVer 三段式结构

一个标准的语义化版本号格式为:MAJOR.MINOR.PATCH,例如 2.5.1。每一段数字都对应特定的变更类型:

段位 名称 变更触发条件 对下游的影响
MAJOR 主版本号 做了不兼容的 API 或功能修改 破坏向后兼容,下游需适配
MINOR 次版本号 新增了向下兼容的功能或 API 向后兼容,下游可安全升级
PATCH 补丁号 做了向下兼容的问题修复 向后兼容,仅修复缺陷
核心原则:版本号一旦发布,就不可修改。任何变更都必须通过递增版本号来发布新版本,禁止对已发布的制品进行覆盖或重写。

3.2 版本号递增规则详解

每次发布新制品时,必须根据变更类型严格递增对应的段位,并重置右侧所有段位为 0:

  • 主版本号递增(MAJOR):当进行了不兼容的 API 修改、架构重构、协议变更或重大功能重写时,递增主版本号。例如从 1.3.2 变为 2.0.0。次版本号和补丁号归零。
  • 次版本号递增(MINOR):当新增了向下兼容的新功能、新接口或新能力时,递增次版本号。例如从 1.3.2 变为 1.4.0。补丁号归零。
  • 补丁号递增(PATCH):当进行了向下兼容的缺陷修复、性能优化或安全补丁时,递增补丁号。例如从 1.3.2 变为 1.3.3。
版本冻结场景示例:假设当前线上运行的是 2.1.0。如果发现一个严重安全漏洞需要紧急修复,且修复不改变 API,则发布 2.1.1。如果同时需要新增一个兼容的日志接口,则发布 2.2.0。如果必须修改数据库表结构且不兼容旧版,则发布 3.0.0。

3.3 预发布版本与构建元数据

SemVer 还支持在正式版本号后附加预发布标识和构建元数据,用于标记非稳定版本或构建环境信息:

  • 预发布版本:在补丁号后添加连字符和标识符,如 1.0.0-alpha.1、2.3.0-rc.2。预发布版本优先级低于正式版本,常用于内测、灰度或候选发布。
  • 构建元数据:在版本号后添加加号和标识符,如 1.0.0+build.20250315。构建元数据不影响版本优先级,仅用于记录构建信息。
类型 格式示例 优先级比较 典型用途
正式版本 1.2.3 最高 生产环境发布
预发布版本 1.2.3-rc.1 低于正式版 候选发布、测试验证
预发布版本 1.2.3-alpha 低于 rc 内部开发、功能预览
构建元数据 1.2.3+sha.abc123 不参与比较 记录构建来源
版本冻结中的注意事项:在版本冻结期间,禁止使用预发布版本或构建元数据作为正式发布版本。冻结策略要求所有进入生产环境的制品必须使用不含预发布标识的正式版本号,以确保回滚时版本比较的准确性和一致性。

3.4 版本号比较与优先级

在制品回滚场景中,版本号的比较直接决定回滚目标的选择。SemVer 的优先级规则如下:

  1. 比较主版本号、次版本号、补丁号,按数值从大到小排序。
  2. 正式版本优先级高于任何预发布版本(如 1.0.0 > 1.0.0-rc.1)。
  3. 预发布版本之间按标识符逐段比较:数字标识符按数值比较,字母标识符按字典序比较。
  4. 构建元数据不参与优先级比较,仅作为附加信息。
回滚场景应用:当需要从 2.1.0 回滚时,系统应自动选择小于 2.1.0 且版本号最大的正式版本。例如,如果制品仓库中存在 2.0.1、2.0.0、1.9.0,则回滚目标应为 2.0.1。预发布版本如 2.0.1-rc.1 不会被选为回滚目标。

3.5 版本号规范在制品回滚中的价值

严格执行 SemVer 规范,能为制品回滚和版本冻结带来以下核心收益:

  • 明确回滚边界:通过主版本号判断是否可安全回滚,避免跨不兼容版本的回滚导致系统故障。
  • 自动化决策依据:CI/CD 流水线可根据版本号自动选择回滚目标,无需人工判断。
  • 版本冻结可追溯:冻结策略可以基于版本号范围定义,如“冻结所有 2.x.x 版本”,清晰且可执行。
  • 降低沟通成本:开发、测试、运维团队通过版本号即可理解变更影响范围。
最佳实践:在制品仓库中,建议为每个制品保留完整的版本历史,并确保版本号严格遵循 SemVer 规范递增。在版本冻结期间,冻结策略应明确指定允许的版本号范围(如 >=2.0.0 <3.0.0),避免使用模糊的“最新版本”描述。