跳转到主要内容
要长期维护 Laravel 包,务必提前建立变更历史和发布流程。将发布管理机制化,可以防止破坏性变更的通知遗漏,也能避免发布工作变得依赖某个人。
本页是Laravel 包开发的姊妹页面。Laravel/PHP 兼容性策略请参考包的版本兼容性管理

CHANGELOG.md 的写法

CHANGELOG 是用户确认「什么变更、何时发生、在哪个版本」的一手信息。采用 Keep a Changelog 格式,可以在团队内统一分类结构。

基本规则

  • ## [x.y.z] - YYYY-MM-DD 作为版本标题
  • 使用 Added / Changed / Deprecated / Removed / Fixed / Security 分类
  • 在末尾放置 Compare 链接,方便追踪差异
  • 尚未发布的变更堆积在 ## [Unreleased]
发布说明可以直接使用 CHANGELOG 中对应版本的内容。将信息源集中到一处后,README、GitHub Releases、社交媒体公告之间就不容易出现偏差。

语义化版本(SemVer)

语义化版本MAJOR.MINOR.PATCH 使用以下标准:
  • MAJOR:破坏后向兼容性的变更(Breaking change)
  • MINOR:保持后向兼容性的新功能
  • PATCH:保持后向兼容性的 Bug 修复

Laravel 包的判断示例

对 Laravel 13 的支持,视变更内容不同处理方式也不同。 请务必在 Upgrade Guide 中确认 Laravel 本体的升级内容。最新版发布情况可在 laravel/framework releases 查看。若你的包使用的 API 有破坏性变更,就需要重新设计兼容策略。
提高 PHP 最低要求或删除公开 API,从用户角度看都是破坏性变更。即使与 Laravel 主版本对齐工作同时进行,也要按 MAJOR 版本发布。

Git 标签与 GitHub Releases

首先打 Git 标签,并推送到 origin。
然后在 GitHub 的 Release 创建界面选择 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 包

了解发布前所需的测试策略与实现方法。
最后修改于 2026年7月18日