116、【Agent】【OpenCode】项目配置（SemVer）（补充）
【声明】本博客所有内容均为个人业余时间创作，所述技术案例均来自公开开源项目（如Github，Apache基金会），不涉及任何企业机密或未公开技术，如有侵权请联系删除
背景
上篇 blog
【Agent】【OpenCode】项目配置（SemVer）
分析了 Lock 文件锁死依赖包版本号的情况下，在package.json里声明版本范围的作用：安全升级通行证（虽然 Lock 文件把当前的环境锁住了，但如果用户需要获取新的 Bug 修复或新功能时，包管理器会在package.json允许的范围内，自动拉取最新的兼容版本，并同步更新本地的 Lock 文件），团队协作的沟通契约（开发者通过版本范围可以知道项目的底线在哪里，哪些版本需要经过严格的代码重构和测试），解决依赖冲的边界线（如果只给一个绝对精确的版本号，稍微有一点错开，整个依赖树可能会因为无法匹配而崩溃报错），接着分析了 SemVer 规范，其中主版本号不兼容重大变更，次版本号向下兼容新增功能，补丁号向下兼容问题修复，下面继续分析
OpenCode
SemVer 官方链接在 https://semver.org/，这里最后再补充点 SemVer 的特殊阶段，除了上篇 blog 介绍的基础三段式数字，SemVer 还允许在版本号后面附加信息，用来表示特殊的开发状态
- 预发布版本（Pre-release）：用来标识尚未正式发布的测试阶段，通常以连字符链接，比如
-alpha（早期测试），-beta（公测），-rc（Release Candidate，最终候选版），比如2.0.0-beta.2 - 构建元数据（Build）：通常用加号
+连接，用来记录具体的编译时间，或者 Git 提交哈希值，这部分信息不影响版本的优先级排序 - 特别注意
0.x.x阶段：按照 SemVer 规范，如果主版本号为 0，比如0.1.0或0.9.9，说明该软件正处于初始开发阶段，在这个阶段，公共 API 是不稳定的，任何更改都可能是不兼容的，无需严格遵守上篇 blog 说的递增规则，只有当发布了1.0.0之后，才代表公共 API 已经稳定，并正式受 SemVer 规范约束
另外，再提一嘴，之前 blog 【Agent】【OpenCode】项目配置（package.json 和 bun.lock） 介绍的^（Caret）和~（Tilde）符号规则，并不在 SemVer 官方规范中，而是包管理器（Npm，Bun 等）自己实现的版本解析策略，官方的 SemVer 规范只定义了版本号【MAJOR.MINOR.PATCH】的含义和递增规则，规定了当开发者看到如1.0.0这个版本号时，该怎样理解其兼容性，但并没有规定工具应该如何去选择版本，而^和~则是 Npm 等工具为了方便开发者锁定兼容范围而发明的语法糖
SemVer 规范只负责定规矩，告诉软件什么样的变更对应什么样的版本号，并没有提到该用什么符号来匹配这些版本，比如
- 破坏性变更，主版本号 + 1
- 向后兼容的功能新增，次版本号 + 1
- 向后兼容的 Bug 修复，修订号 + 1
而 Npm，Bun 等包管理器负责抓取和匹配，为了方便开发者在package.json里声明依赖范围，Npm 定义了
^（Caret）：根据 SemVer 规范，只要主版本号不变，后面怎么变都是兼容的，所以^1.2.3被解释为1.2.3 ≤ 版本号 < 2.0.0~（Tilde）：其逻辑更保守，只能 Bug 修复，连新功能都不需要，所以~1.2.3被解释为1.2.3 ≤ 版本号 < 1.3.0
OK，本篇先到这里，如有疑问，欢迎评论区留言讨论，祝各位功力大涨，技术更上一层楼！！！更多内容见下篇 blog