このページはLaravelパッケージ開発の姉妹ページです。Laravel/PHP互換性の戦略はパッケージのバージョン互換性管理を参照してください。
CHANGELOG.md の書き方
CHANGELOGは「何が、いつ、どのバージョンで変わったか」を利用者が確認する一次情報です。フォーマットはKeep a Changelogを採用すると、カテゴリ構成をチームで統一できます。基本ルール
## [x.y.z] - YYYY-MM-DD形式でバージョンを見出しにするAdded / Changed / Deprecated / Removed / Fixed / Securityを使う- Compareリンクを末尾に置いて差分を追えるようにする
- まだ未リリースの変更は
## [Unreleased]に積む
セマンティックバージョニング(SemVer)
Semantic VersioningではMAJOR.MINOR.PATCH を次の基準で使います。
- MAJOR: 後方互換性を壊す変更(Breaking change)
- MINOR: 後方互換性を保った機能追加
- PATCH: 後方互換性を保ったバグ修正
Laravelパッケージでの判断例
Laravel 13対応は、変更内容で扱いが変わります。| 変更 | 推奨バージョン |
|---|---|
既存Laravel 12対応を維持しつつ ^13.0 を追加 | MINOR |
Laravel 11/12サポートを打ち切って ^13.0 のみにする | MAJOR |
| Laravel 13でのみ発生する不具合修正 | PATCH |
GitタグとGitHub Releases
まずGitタグを打ち、タグをoriginにpushします。v2.1.0 を選択して公開します。本文にはCHANGELOGの ## [2.1.0] セクションを貼り付けてください。
GitHub Actions による自動リリース
push: tags: をトリガーにすると、タグ作成を起点にGitHub Releasesを自動公開できます。softprops/action-gh-release を使うと、CHANGELOG.md の内容を直接本文に流用できます。
release ジョブに needs: test を設定すると、テスト失敗時に公開を止められます。手動リリースでも自動リリースでも、このゲートは必ず維持してください。Breaking changes の扱い方
Breaking changeは段階的に移行できる設計にしてください。まず非推奨化し、次のMAJORで削除すると、利用者の移行コストを下げられます。1. 非推奨化をコードで示す
2. 移行ガイドをドキュメント化する
UPGRADE.md または専用ページで、あなたが利用者に実施してほしい変更を手順化してください。
3. メジャーバージョン間の移行ノートを残す
MAJORを上げるときは、CHANGELOGのRemoved と移行ガイドを相互リンクしてください。利用者は「何が削除されたか」と「どう直すか」を1回で追えます。
関連ページ
Laravelパッケージ開発
サービスプロバイダーを中心にした実装の基礎を確認します。
パッケージのバージョン互換性管理
Laravel/PHP互換性とSemVer運用の判断基準を整理します。
Orchestra TestbenchでLaravelパッケージをテストする
リリース前に必要なテスト戦略と実装方法を確認します。