语义化版本是什么
SemVer 把版本号定义为 MAJOR.MINOR.PATCH 三段，各自含义明确：不兼容变更升主版本、向后兼容的新增功能升次版本、兼容的问题修复升修订号。可选后缀区分预发布（-rc.1、-beta.2）与构建元数据（+build.20261012）。0.y.z 表示初始开发阶段，语义上不承诺稳定，任何版本都可能包含不兼容变更。它的价值在于让依赖解析、升级评估与发布自动化有统一的机器可读语言：工具能根据版本号判断一次升级是否可能破坏调用方。对调用方而言，把它写进依赖声明配合范围语法（如部分包管理器的插入符表示兼容升级），自动升级才安全可预期；对发布方而言，混乱的版本号会直接破坏这个生态契约。
基本信息
| 格式 | MAJOR.MINOR.PATCH 加可选预发布与构建元数据 |
|---|---|
| 规则 | 主版本不兼容、次版本兼容新增、修订号兼容修复 |
| 0.y.z | 初始开发阶段，任何版本都可能包含不兼容变更 |
| 预发布 | 如 1.9.0-rc.1，优先级低于同号正式版 |
| 构建元数据 | 如 1.9.0+build.5，不参与版本比较 |
| 范围语法 | 包管理器的插入符与波浪号等范围建立在三段语义上 |
| 应用范围 | npm、pip、Go modules 等生态基于语义化版本或其变体 |
典型使用场景
- 发布库与包：依赖解析按版本规则选择升级范围，语义是自动化决策的前提。
- API 变更沟通：主版本升级是对调用方明确的破坏性信号，配合迁移说明发布。
- CI 发布流水线：从标签或提交约定推导版本号，打制品标签并生成变更日志。
- 预发布通道：rc、beta 先给内部验证，不进入正式依赖范围。
- 制品追溯：版本号与发布记录、变更日志、镜像标签对齐。
- 单仓多包：统一版本或独立版本策略要写清纪律，避免各包规则不一。
- 依赖升级评估：升级机器人按语义判断升级风险等级。
- 安全公告：漏洞影响范围用版本区间表达，扫描器按语义匹配受影响版本。
- 废弃流程：先标记废弃并用次版本发布替代方案，主版本再移除，给调用方留迁移窗口。
示例与比较
示例与比较
1.8.0 正式版本
2.0.0 含不兼容变更
1.9.0-rc.1 预发布（优先级低于 1.9.0）
1.9.0+build.20261012 构建元数据（不参与比较）
# 比较顺序示例：
# 1.9.0-rc.1 < 1.9.0 < 1.9.1 < 1.10.0 < 2.0.0变更类型对照
| 变更类型 | 应升哪段 | 示例 |
|---|---|---|
| 不兼容修改 | MAJOR | 1.8.1 到 2.0.0 |
| 向后兼容新增 | MINOR | 1.8.1 到 1.9.0 |
| 兼容问题修复 | PATCH | 1.8.0 到 1.8.1 |
| 开发期任意变更 | 0.y.z 内 | 0.9.0 到 0.10.0 |
| 废弃功能 | MINOR 标废弃 MAJOR 移除 | 1.8 标注 2.0 移除 |
版本号一旦发布不再修改内容：打错了先升修订号重发，而不是覆盖原版本，否则依赖锁与审计记录全部失真。
预发布版本按点号分段比较：rc.2 高于 rc.1；数字分段不能带前导零。构建元数据在比较时被忽略，不要用它表达顺序信息。
单仓多包建议：要么全仓统一版本、要么各包独立语义版本，两种皆可，混着来最难维护。
很多依赖范围默认不匹配预发布版本：把预发布号当正式版对外发布，调用方的自动升级与解析行为会出乎预期。