Skip to main content
若您要長期維護 Laravel 套件,請先整備變更歷史與發布程序。將發布管理機制化,可避免破壞性變更遺漏公告、以及發布作業屬人化。
本頁為Laravel 套件開發的姊妹頁。Laravel/PHP 相容性策略請參考套件的版本相容性管理

CHANGELOG.md 的寫法

CHANGELOG 是使用者確認「什麼、於何時、於哪個版本變動」的一手資訊。若採用 Keep a Changelog 的格式,可於團隊間統一分類結構。

基本規則

  • ## [x.y.z] - YYYY-MM-DD 格式作為版本標題
  • 使用 Added / Changed / Deprecated / Removed / Fixed / Security
  • 於文末放置 Compare 連結以便追蹤差異
  • 尚未發布的變更累積於 ## [Unreleased]
Release Notes 請直接沿用 CHANGELOG 對應版本。將歷史資訊來源集中於一處,可讓 README、GitHub Releases 與 SNS 公告內容不易失準。

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,則需重新設計相容性政策。
提升 PHP 最低要求或刪除公開 API,對使用者而言即為 Breaking change。即便與 Laravel 主版本對應同時進行,也應視為 MAJOR release。

Git tag 與 GitHub Releases

先建立 Git tag,並 push 至 origin。
接著於 GitHub 的 Release 建立畫面選擇 tag 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 套件

確認發布前所需的測試策略與實作方式。
最後修改於 2026年8月2日