本页是Laravel 包开发的姊妹页面。Laravel/PHP 兼容性策略请参考包的版本兼容性管理。
CHANGELOG.md 的写法
CHANGELOG 是用户确认「什么变更、何时发生、在哪个版本」的一手信息。采用 Keep a Changelog 格式,可以在团队内统一分类结构。基本规则
- 以
## [x.y.z] - YYYY-MM-DD作为版本标题 - 使用
Added / Changed / Deprecated / Removed / Fixed / Security分类 - 在末尾放置 Compare 链接,方便追踪差异
- 尚未发布的变更堆积在
## [Unreleased]
语义化版本(SemVer)
语义化版本中MAJOR.MINOR.PATCH 使用以下标准:
- MAJOR:破坏后向兼容性的变更(Breaking change)
- MINOR:保持后向兼容性的新功能
- PATCH:保持后向兼容性的 Bug 修复
Laravel 包的判断示例
对 Laravel 13 的支持,视变更内容不同处理方式也不同。
请务必在 Upgrade Guide 中确认 Laravel 本体的升级内容。最新版发布情况可在 laravel/framework releases 查看。若你的包使用的 API 有破坏性变更,就需要重新设计兼容策略。
Git 标签与 GitHub Releases
首先打 Git 标签,并推送到 origin。v2.1.0 标签发布。正文中粘贴 CHANGELOG 中 ## [2.1.0] 段落即可。
1
将待发布提交合入 main
在测试全部通过的状态下将其合并到
main。2
创建 Git 标签并推送
以
vX.Y.Z 形式创建标签并推送到 origin。3
发布 GitHub Release
标题使用标签名,正文使用 CHANGELOG 对应条目。
使用 GitHub Actions 自动发布
以push: tags: 作为触发器,可以在创建标签时自动发布 GitHub Releases。使用 softprops/action-gh-release 时可以直接把 CHANGELOG.md 的内容作为正文。
为
release job 设置 needs: test 后,测试失败时可以阻止发布。无论手动还是自动发布,都请保留这道闸门。破坏性变更的处理方式
破坏性变更应设计为可分阶段迁移。先标记废弃,在下一个 MAJOR 版本再删除,这样能降低用户的迁移成本。1. 在代码中标记废弃
2. 将迁移指南文档化
在UPGRADE.md 或专用页面中,把希望用户执行的变更步骤化。
3. 保留主版本间的迁移说明
升 MAJOR 版本时,把 CHANGELOG 的Removed 与迁移指南互相链接。这样用户可以一次搞清楚「删除了什么」与「怎么修改」。
相关页面
Laravel 包开发
了解以 Service Provider 为中心的实现基础。
包的版本兼容性管理
整理 Laravel/PHP 兼容性与 SemVer 运营的判断标准。
使用 Orchestra Testbench 测试 Laravel 包
了解发布前所需的测试策略与实现方法。