如何为我的 composer 包遵循语义化版本 (SemVer) 规范？

遵循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 会自动抓取这个标签，并将其作为新版本发布。

拍我AI

AI视频生成平台PixVerse的国内版本

190

查看详情

保持 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。这会让依赖你包的开发者更安心地更新版本。

以上就是如何为我的 composer 包遵循语义化版本 (SemVer) 规范？的详细内容，更多请关注php中文网其它相关文章！