本頁為Laravel 套件開發的姊妹頁。Laravel/PHP 相容性策略請參考套件的版本相容性管理。
CHANGELOG.md 的寫法
CHANGELOG 是使用者確認「什麼、於何時、於哪個版本變動」的一手資訊。若採用 Keep a Changelog 的格式,可於團隊間統一分類結構。基本規則
- 以
## [x.y.z] - YYYY-MM-DD格式作為版本標題 - 使用
Added / Changed / Deprecated / Removed / Fixed / Security - 於文末放置 Compare 連結以便追蹤差異
- 尚未發布的變更累積於
## [Unreleased]
Semantic Versioning(SemVer)
Semantic Versioning 中的MAJOR.MINOR.PATCH 依下列基準使用。
- MAJOR:破壞後向相容性的變更(Breaking change)
- MINOR:保持後向相容性的功能新增
- PATCH:保持後向相容性的 bug 修正
Laravel 套件的判斷範例
Laravel 13 的支援,會依變更內容有不同處理。
Laravel 本體升級內容請務必於 Upgrade Guide 確認。最新版發布狀況可於 laravel/framework releases 確認。若您的套件所使用的 API 有 Breaking change,則需重新設計相容性政策。
Git tag 與 GitHub Releases
先建立 Git tag,並 push 至 origin。v2.1.0 並公開。本文請貼上 CHANGELOG 的 ## [2.1.0] 段落。
1
將 Release 對象 commit merge 至 main
於測試全部通過的狀態下 merge 至
main。2
建立 Git tag 並 push
建立
vX.Y.Z 格式的 tag,push 至 origin。3
公開 GitHub Release
標題使用 tag 名,本文使用 CHANGELOG 對應項目。
使用 GitHub Actions 自動化發布
以push: tags: 作為觸發,可以 tag 建立為起點自動公開 GitHub Releases。使用 softprops/action-gh-release,可將 CHANGELOG.md 內容直接沿用為本文。
於
release job 設定 needs: test 後,測試失敗時可阻止公開。無論手動或自動 release,此 gate 皆應維持。Breaking changes 的處理方式
請將 Breaking change 設計為可分階段遷移。先標示為 deprecated,再於下一個 MAJOR 刪除,可降低使用者的遷移成本。1. 於程式碼中標示 deprecated
2. 將遷移指南文件化
於UPGRADE.md 或專屬頁面,將希望使用者進行的變更文件化為步驟。
3. 保留主版本間的遷移備註
提升 MAJOR 時,請將 CHANGELOG 的Removed 與遷移指南互相連結。使用者一次即可追蹤「什麼被刪除了」與「如何修正」。
相關頁面
Laravel 套件開發
確認以服務提供者為核心的實作基礎。
套件的版本相容性管理
整理 Laravel/PHP 相容性與 SemVer 運用的判斷基準。
以 Orchestra Testbench 測試 Laravel 套件
確認發布前所需的測試策略與實作方式。