Semantic Versioning
语义化版本
语义化版本（SemVer）用“主版本号.次版本号.修订号”（MAJOR.MINOR.PATCH）表示公开 API 如何改变，也规定预发布和构建标记的写法。
另一个例子
一个程序库目前是 2.4.1，并新增不会破坏旧代码的 API。维护者发布 2.5.0 并记录新增内容；如果没有先说明公开 API，这些版本号就无法清楚表示兼容性。
主要部分
- 01公开 API
- 02兼容性变更
- 03版本标识符
什么时候用
软件有清楚的公开 API，而且版本号用来表示兼容性变化时，可以使用这个词。
什么时候不要用
不要只看 SemVer 版本号，就推测产品质量、发布日期或升级要花多少工作。
代码里的名称
MAJOR.MINOR.PATCH[-prerelease][+build] 上线前要检查
检查程序运行环境与版本、集成边界、依赖与许可，以及支持的平台。验证安全、失败处理、性能与监控。也要检查部署、支持负责人、升级路径与恢复上一版的方法。
预期结果：把 语义化版本 (Semantic Versioning) 当作团队能维护的技术基础，并检查它是否符合产品需求。 用户场景：一个程序库目前是 2.4.1，并新增不会破坏旧代码的 API。维护者发布 2.5.0 并记录新增内容；如果没有先说明公开 API，这些版本号就无法清楚表示兼容性。 技术或工程概念：语义化版本 (Semantic Versioning)。 适用理由：软件有清楚的公开 API，而且版本号用来表示兼容性变化时，可以使用这个词。 不应使用的情况：不要只看 SemVer 版本号，就推测产品质量、发布日期或升级要花多少工作。 工程适配：定义程序运行环境与版本。说明它负责什么、接口、数据流、依赖、支持平台、安全与性能限制，以及如何接入现有技术组合。 生命周期防护：检查依赖是否健康、许可是否可用。加入监控与安全备用做法，并指定升级负责人。没有可衡量的好处时，不要再加入功能重复的框架或工具。 验收标准：用最小集成证明必要行为。测试兼容性、安全性、失败与性能。记录部署、升级、支持与恢复上一版的方法。 证据与限制（证据边界）：正式文档仍可能是草案、候选版或最终版。请查看文档状态，也要确认浏览器或平台是否支持。 待确认：现有技术组合、运行环境、版本规则、目标平台和依赖负责人。也要确认性能预算、支持期限与迁移限制。
检查这份需求
请 AI 编程助手检查当前如何使用 语义化版本 (Semantic Versioning)。 定义：语义化版本（SemVer）用“主版本号.次版本号.修订号”（MAJOR.MINOR.PATCH）表示公开 API 如何改变，也规定预发布和构建标记的写法。 生产环境检查：检查程序运行环境与版本、集成边界、依赖与许可，以及支持的平台。验证安全、失败处理、性能与监控。也要检查部署、支持负责人、升级路径与恢复上一版的方法。 修改程序前，先列出看到的证据、缺口、严重程度，以及最小且安全的修正。