遵循SemVer需正确使用MAJOR.MINOR.PATCH版本格式：不兼容API变更递增主版本号，新增向后兼容功能递增次版本号，修复bug递增修订号；通过git标签（如v1.1.0）发布版本，Packagist自动同步；保持公共API兼容，破坏性变更须升级主版本并记录；维护CHANGELOG.md说明各版本变更内容，确保依赖者安全升级。
为你的 composer 包遵循语义化版本（SemVer）规范，关键在于正确理解并应用版本号的格式 MAJOR.MINOR.PATCH，并根据代码变更的类型递增相应的部分。
理解 SemVer 版本结构
SemVer 使用三位数字表示版本：X.Y.Z，分别对应主版本号、次版本号和修订号。每次发布新版本时，依据变更类型决定哪一位需要增加：
- MAJOR（X）：当你做了不兼容的 API 修改时递增
- MINOR（Y）：当你以向后兼容的方式添加新功能时递增
- PATCH（Z）：当你进行向后兼容的问题修复时递增
例如，从 1.2.3 升级到：
- 1.2.4 → 仅修复 bug
- 1.3.0 → 添加了新功能，但没有破坏现有功能
- 2.0.0 → 引入了不兼容的变更
在 composer.json 中设置版本
你不需要手动修改 composer.json 中的版本号。Composer 会根据 Git 标签来识别版本。你应该做的是：
- 使用 Git 管理代码
- 每次发布新版本时打一个标签，如 v1.0.0
- 确保标签格式为 vX.Y.Z（v 是可选的，但推荐）
示例：
git tag v1.1.0 git push origin v1.1.0
Packagist 会自动抓取这个标签，并将其作为新版本发布。
保持 API 兼容性
为了真正遵循 SemVer，你需要对公共 API 的变更格外小心：
- 不要删除或重命名公共类、方法或函数
- 不要更改方法签名（参数数量、类型等）
- 添加新方法或类属于 MINOR 变更
- 修复行为错误属于 PATCH 变更
如果你必须打破兼容性，就升级主版本号（MAJOR），并清楚地记录变更内容。
撰写清晰的变更日志
维护一个 CHANGELOG.md 文件，列出每个版本的变更类型（新增、修复、破坏性变更），帮助用户判断是否可以安全升级。例如：
## v2.0.0 (2025-04-05) ### Breaking Changes - 移除了废弃的 MyClass::oldMethod() - 更改了 SomeService 构造函数参数 <h2>v1.1.0 (2025-03-20)</h2><h3>Added</h3><ul><li>新增了 Helper::formatOutput() 方法
基本上就这些。只要坚持按规则打标签、管理变更类型，并保持透明沟通，你的 Composer 包就能良好地遵循 SemVer。这会让依赖你包的开发者更安心地更新版本。