release

ActivityPub のリリースプロセス

WordPress ActivityPub プラグインのリリースと変更履歴を管理するためのクイックリファレンスです。

クイックリファレンス

リリースコマンド

npm run release              # Create major/minor release PR.

バージョンファイルの場所

バージョンを手動で更新する場合は、次のファイルを変更してください（これらは bin/release.js が変更するファイルです）。

• activitypub.php - プラグインヘッダー（Version: X.Y.Z）および ACTIVITYPUB_PLUGIN_VERSION 定数。両方を変更する必要があります。
• readme.txt - WordPress.org の readme（Stable tag: X.Y.Z）。
• includes/class-migration.php - DB 移行の version_compare() チェック内のバージョン参照。
• CHANGELOG.md - 変更履歴ファイル（リリーススクリプトによって自動更新されます）。

注：package.json には version フィールドがなく、リリース時のバージョン更新の対象ではありません。

詳細なリリースガイド

リリースワークフローと詳細な手順については、リリースプロセスを参照してください。

リリースワークフロー

メジャー／マイナーリリース

クイックワークフロー：

# 1. Run release script from plugin root.
npm run release

# Script automatically:
# - Determines version from changelog entries.
# - Updates version numbers in all files.
# - Updates CHANGELOG.md.
# - Creates PR for review.

# 2. Review and merge the release PR.

# 3. Create GitHub release from trunk using the new tag.

詳しい手順については、リリースプロセス - メジャー／マイナーを参照してください。

パッチリリース

クイックワークフロー：

# 1. Create branch from the tag to patch.
git fetch --tags
git checkout -b tags/5.3.1 5.3.0  # Patch 5.3.0 -> 5.3.1

# 2. Cherry-pick merge commits from trunk (note -m 1 flag).
git cherry-pick -m 1 <commit-hash>

# 3. Update changelog and versions.
composer changelog:write

# Manually update versions in (see Version File Locations above):
# - activitypub.php (Version header AND ACTIVITYPUB_PLUGIN_VERSION constant)
# - readme.txt
# - includes/class-migration.php

# 4. Push branch and create GitHub release.
git push -u origin tags/5.3.1

重要： マージコミットをチェリーピックするときは、メインラインの親を選択するために -m 1 フラグを使用してください。

詳しい手順については、リリースプロセス - パッチリリースを参照してください。

変更履歴の管理

仕組み

変更履歴は PR ワークフローを通じて自動的に管理されます。

1. PR テンプレート（.github/PULL_REQUEST_TEMPLATE.md）：

   • 「Automatically create a changelog entry」チェックボックスをオンにします。
   • 重要度を選択します：Patch／Minor／Major。
   • 種類を選択します：Added／Fixed／Changed／Deprecated／Removed／Security。
   • 句読点で終わるメッセージを書きます。

2. GitHub Action（.github/workflows/changelog.yml）：

   • PR の説明から変更履歴ファイルを作成します。
   • 適切な句読点が使われているか検証します。
   • .github/changelog/ ディレクトリに保存します。

3. リリースプロセス：

   • npm run release ですべてのエントリーをまとめます。
   • CHANGELOG.md と readme.txt を自動的に更新します。

重要な要件

変更履歴のメッセージは必ず句読点で終わらせてください：

✅ Add support for custom post types.
✅ Fix signature verification bug.
❌ Add support for custom post types
❌ Fix signature verification bug

エンドユーザーにわかりやすいメッセージを書いてください：

• 実装の詳細ではなく、ユーザーにとってのメリットに重点を置きます。
• 可能な限り専門用語を避けます。
• 内部でどのように機能するかではなく、ユーザーが新たにできるようになったことを説明します。

✅ Add pre-built block patterns for easy profile and sidebar setup.
✅ Fix follow button not appearing on author pages.
❌ Add register_patterns() method to class-blocks.php.
❌ Refactor User class to use Actors collection.

実際のインストール環境で何が壊れるかを基準に、重要度を選んでください：

• major はプラグインのバージョンを次の整数バージョンに上げるため、それに見合う変更でなければなりません。以前と同じ使い方を続けるユーザーにとって、実際のインストール環境が依存する機能において、明らかに悪化する結果や破壊的な結果が生じる場合が該当します。公開定数の削除や、オプトインの実験的機能の破損は major には該当しません。WordPress または PHP の最小バージョンの引き上げは、必ず該当します。
• 破損を主張する前に、実際に何かが壊れたことを確認してください。

ユーザーに見える変更ごとにエントリーを 1 つ作成します。 無関係な修正は別々のファイルに分けますが、同じユーザー表示項目に対する複数の修正は、それらが解決する問題の数にかかわらず、1 つのエントリーにまとめます。

リリースされていないバージョンにしか存在しなかったバグについては、エントリーを作成しません。 同じ未リリースブランチで導入された問題の修正は、ユーザーにとって差し引きゼロです。

リリース PR の本文は中立的に保ちます。 リリーススクリプトが出力するプレーンテキストを使用し、リリース PR やそのノートでセキュリティ修正を列挙したり、ことさらに取り上げたりしないでください。

変更履歴のメッセージで AI ツールやコーディングアシスタントに言及しないでください。

変更履歴の要件の詳細については、PR ワークフロー - 変更履歴を参照してください。

バージョン番号

セマンティックバージョニング：

• Major (X.0.0) - 互換性を破壊する変更。
• Minor (0.X.0) - 後方互換性のある新機能。
• Patch (0.0.X) - バグ修正のみ。

リリーススクリプトは、変更履歴エントリーの重要度に基づいてバージョンを自動的に決定します。