本文目录
什么是语义化版本？
语义化版本（SemVer）是一种为版本号的每个部分赋予明确含义的版本命名方案。它由 Tom Preston-Werner 提出，提供了一套通用约定，仅凭版本号本身就能传达软件变更的性质与影响。
遵循 SemVer，开发者和用户只需读一读版本号，就能立即判断某次更新引入的是破坏性变更、新功能还是 Bug 修复。这种可预测性对于现代软件生态中的依赖管理至关重要。
SemVer 格式
一个语义化版本由三个以点号分隔的数字组成：MAJOR.MINOR.PATCH（主版本.次版本.修订号）。
- MAJOR（主版本）——当你做出不兼容的 API 变更时递增。从 1.x.x 升到 2.0.0 表明现有代码可能会失效
- MINOR（次版本）——当你以向后兼容的方式新增功能时递增。从 1.2.x 升到 1.3.0 意味着新增了功能，且不破坏现有功能
- PATCH（修订号）——当你做出向后兼容的 Bug 修复时递增。从 1.2.3 升到 1.2.4 意味着仅修复了 Bug
- 每个部分都必须是非负整数，且不得包含前导零（1.02.3 是无效的）
免费试用 —— 无需注册
校验 SemVer 字符串 →版本范围与约束
包管理器使用版本范围来指定兼容的依赖版本。理解这些范围对于实现可靠的构建至关重要。
- 脱字符范围（^1.2.3）——允许不改变最左侧非零数字的变更。^1.2.3 表示从 1.2.3 起、直到但不包含 2.0.0 的任意版本
- 波浪号范围（~1.2.3）——仅允许修订号级别的变更。~1.2.3 表示从 1.2.3 起、直到但不包含 1.3.0 的任意版本
- 精确版本（1.2.3）——只接受该特定版本，没有任何灵活性
常见适用场景
语义化版本是现代包管理和发布流程的基石。
- npm、pip 和 Cargo——包管理器依靠 SemVer 来解析依赖树，防止破坏性变更进入生产环境
- CI/CD 流水线——自动化系统利用 SemVer 标签来触发构建、发布版本以及生成变更日志
- API 版本控制——REST API 在 URL 中使用主版本号（v1、v2），以便在演进的同时保持向后兼容
- 库的作者——发布一个采用规范 SemVer 的库，可以向使用者传达何时可以安全升级
预发布版本与构建元数据
SemVer 支持两个可选的扩展，它们可在不影响优先级规则的前提下为版本号补充上下文信息。
- 预发布标识符——追加在连字符之后：1.0.0-alpha、1.0.0-beta.2、1.0.0-rc.1。它们表示尚不稳定的版本，其优先级低于对应的正式版本
- 构建元数据——追加在加号之后：1.0.0+build.123、1.0.0-beta+exp.sha.5114f85。在判定版本优先级时，构建元数据会被忽略
- 预发布版本按点号分隔的标识符进行排序：纯数字标识符按数值排序，字母数字标识符按字典序排序
常见问题
0.x.x 的处理方式与 1.x.x 有所不同吗？
是的。在 SemVer 中，0.x.x 版本表示处于初期开发阶段，此时任何内容都可能随时变更，公共 API 不应被视为稳定。一旦你发布 1.0.0，就意味着承诺在此后的所有版本中都遵循 SemVer 规则。
我可以使用 v 作为前缀吗（v1.2.3）？
SemVer 规范本身并不包含 v 前缀——其规范格式是 1.2.3。不过，许多工具（Git 标签、GitHub 发布版本）习惯上会使用 v1.2.3。大多数校验器两种形式都能接受。
如果我在做破坏性变更时忘记提升主版本号，会怎样？
使用脱字符范围的用户将自动收到该更新，他们的构建可能会意外失败。这正是 SemVer 纪律至关重要的原因——它是库的作者与使用者之间的一份社会契约。