コード貢献 - Gutenbergリリースプロセス（Gutenberg Release Process）

グーテンベルクプラグインのリリース
NPMへのパッケージリリースとWordPressコアの更新

グーテンベルクプラグインのリリース

グーテンベルクプラグインの安定版をリリースする最初のステップは、グーテンベルクリポジトリでイシューを作成することです。イシューのテンプレートは「グーテンベルクリリース」と呼ばれ、リリース候補から変更履歴のキュレーション、チェリーピッキング、安定版リリース、リリース投稿までの完全なリリースプロセスのチェックリストが含まれています。グーテンベルク15.7のイシューは良い例です。

このチェックリストは、リリースプロセスに関与する開発者や他のチームとの調整を助けます。すべての必要なステップが完了し、全員がスケジュールや重要なマイルストーンを把握していることを保証します。

グーテンベルクプラグインのリリース

リリース管理

各メジャーグーテンベルクリリースは、リリースマネージャー、またはリリースリードとして知られる個人によって運営されます。この個人または少数のチームは、広範なグーテンベルク開発チームのサポートを受けて、グーテンベルクのリリースを担当します。

リリースマネージャーは、すべてのリリース活動を開始する責任があり、リリース計画の変更には彼らの承認が必要です。緊急事態が発生した場合やリリースマネージャーが不在の場合、他のチームメンバーが適切な行動を取ることができますが、リリースマネージャーには情報を提供する必要があります。

もしあなたがグーテンベルク開発チームのメンバーで、グーテンベルクリリースをリードすることに興味がある場合は、＃core-editorのSlackチャンネルで連絡してください。

リリースの準備

プラグインのリリースプロセスはほとんど自動化されており、GitHubで行われます。ローカルのマシンで手順を実行する必要はありません。ただし、変更履歴の準備、一般的なテスト、および複数のリリース候補が必要な場合に備えて、グーテンベルクのローカルコピーを持っておくことは良いアイデアです。しかし、その詳細については後で説明します。

プラグインのリリースプロセスを示す11分のビデオがあります。このプロセスに不慣れな場合は、最初にビデオを見ることをお勧めします。このプロセスは、以下の段落にも文書化されており、より詳細な指示が提供されています。

マイルストーンPRの整理とラベリング

クイックリファレンス

すべてのPRが適切にラベル付けされていることを確認してください。
各PRには[Type]で始まる1つのラベルが必要です。

グーテンベルクリリースの準備の最初のステップは、現在のマイルストーンに割り当てられたすべてのPRを整理し、各PRが適切にラベル付けされていることを確認することです。ラベルは、変更履歴を自動的に生成するために使用され、PRのラベルを変更する方が、リリースセクションで既存の変更履歴を再整理するよりもはるかに速いです。

リリースワークフローの一部として実行される変更履歴の自動化をテストするには、作業中の安定版バージョンのマイルストーンを使用して、グーテンベルクのローカルコピーで次のコマンドを使用できます：

npm run other:changelog -- --milestone="Gutenberg 16.2"

このコマンドの出力は、上記の例であるグーテンベルク16.2の提供されたマイルストーンの変更履歴です。出力をMarkdownドキュメントにコピー＆ペーストすると、表示が容易になり、各PRへのリンクをたどることができます。

すべてのPRには[Type]で始まるラベルとサブカテゴリのラベルが必要です。最も一般的な2つのラベルは[Type] Bugと[Type] Enhancementです。生成された変更履歴をレビューする際は、以下の点に注意してください：

強化: サブカテゴリが付いていないPRを探してください。
バグ修正: サブカテゴリが付いていないPRも探してください。
その他: このセクションのPRにはラベルが付いていません。

必要に応じて各PRのラベルを更新してください。快適に進めるまで変更履歴を生成し続けることができます。これでリリース候補ワークフローを開始する準備が整いました。

PRラベルから変更履歴が生成される様子は、changelog.jsファイルで確認できます。

リリースワークフローの実行

クイックリファレンス

#core-editorでリリースワークフローを開始することを発表します。
Build Gutenberg Plugin Zipワークフローを実行します。

始める前に、#core-editorのSlackチャンネルでリリースワークフローを開始することを発表し、安定版のグーテンベルクをリリースするのか、RCをリリースするのかを示します。

次に、グーテンベルクリポジトリに移動し、アクションタブをクリックし、Build Gutenberg Plugin Zipアクションを見つけます。「このワークフローにはworkflow_dispatchイベントトリガーがあります」という青いバナーに注意してください。その右側の「ワークフローを実行」ドロップダウンを展開します。

プラグインリリースのためのワークフロードロップダウン

プラグインのRCバージョンをリリースするには、テキストフィールドにrcを入力します。安定版をリリースするには、stableを入力します。いずれの場合も、「ワークフローを実行」ボタンを押します。

これにより、GitHub Actions (GHA)ワークフローがトリガーされ、プラグインバージョンが増加し、グーテンベルクプラグイン.zipファイルがビルドされ、リリースドラフトが作成され、プラグイン.zipファイルが添付されます。このプロセスのこの部分は通常約6分かかります。ワークフローはリストの一番上に表示され、青いバナーのすぐ下に表示されます。完了すると、ワークフローのステータスアイコンは黄色の点から緑のチェックマークに変わります。ワークフローをクリックして、より詳細なビューを確認できます。

@wordpressパッケージをNPMに公開する

リリースワークフローの一環として、すべての@wordpressパッケージがNPMに公開されます。Build Gutenberg Plugin Zipアクションがドラフトリリースを作成した後、Publish npm packagesアクションをトリガーするために適切な権限を持つ誰かが必要であるというメッセージが表示されることがあります。

このメッセージは誤解を招くものです。@wordpressパッケージをNPMに公開するために、何らかのアクションを取る必要はありません。このプロセスは自動化されており、リリースノートが公開された後に自動的に実行されます。

リリースドラフトの表示

ワークフローが完了すると、グーテンベルクリリースの下にリリースドラフトが見つかります。ドラフトは、このバージョンの以前のRCに基づいて変更履歴エントリで事前に入力されており、それ以降にリリースブランチにチェリーピックされた変更が含まれています。したがって、シリーズの最初の安定版をリリースする際には、RCバージョンのヘッダー（これは情報のためだけに存在します）を削除し、最近の変更を正しいセクションに移動します（以下を参照）。

リリース変更履歴のキュレーション

変更履歴に取り組む最適なタイミングは、リリース候補ワークフロー中に最初に作成されたときです。このとき、変更履歴の自動化が呼び出され、変更履歴の最初のバージョンが利用可能になります。変更履歴プロセスはほとんど自動化されていますが、上記のようにマイルストーン内のPRの適切なラベリングに大きく依存しています。

安定版リリースプロセスは、RCの変更履歴を取り込み、安定版リリースに追加します。ただし、重要な点があります：安定版リリースは、RC1が公開されたときに利用可能だった変更履歴の最初のバージョンのみを「記憶」します。RC1の変更履歴に対するその後の変更は、安定版リリースには含まれません。

つまり、RC1を公開する前に変更履歴全体をキュレーションすれば、安定版リリースのためにそれに取り組む必要はなく、RC2やRC3リリースのいくつかの項目だけが安定版リリースに追加されます。

リリース変更履歴がドラフトで利用可能になったら、メモを読み、読みやすく正確であることを確認するために編集する時間を取ってください。この部分を急がないでください。リリースノートができるだけ整理されていることを確認することが重要ですが、一度にすべてを終わらせる必要はありません。ドラフトを保存して後で戻ることができます。

リリース候補バージョンに人々がアクセスできないのではないかと心配している場合は、リリースアーティファクトを#core-editorのSlackチャンネルで共有できます。これにより、変更履歴のキュレーションを完了するまで、リリース候補バージョンに人々がアクセスできるようになります。

明確で簡潔な変更履歴を準備するための追加のヒントは次のとおりです：

Variousセクションのすべてのエントリをより適切なセクションに移動します。
スペルミスを修正したり、言葉を明確にしたりします。フレーズは、プラグインを使用する人々や進行中の開発を追跡している人々を対象とすることを考慮して、理解しやすいものであるべきです。
適用可能な場合は新しいグループを作成し、PRを移動します。
複数のPRが同じタスクに関連している場合（たとえば、フォローアップのプルリクエストなど）、それらを1つのエントリにまとめるようにしてください。これに関する良い例は、パフォーマンス目的でLodashを削除するPR、Puppeteer E2DテストをPlaywrightに置き換えるPR、または公開コンポーネントをTypeScriptに変換するための取り組みです。
関連するPRのサブタスクが重要な場合は、ネストされたリストのエントリとして整理することを検討してください。
コードの純粋な変更がゼロの場合、同じリリース内の他のPRを元に戻すPRは削除します。
モバイルアプリのみを更新するPRはすべて削除します。このルールの唯一の例外は、モバイルアプリのプルリクエストがWebの機能も更新する場合です。
サブヘッダーに1つのPRしかリストされていない場合は、サブヘッダーを削除し、PRを複数のアイテムがリストされている次の一致するサブヘッダーに移動します。

リリース候補パッチの作成（チェリーピッキング）

クイックリファレンス

チェリーピッキングが必要なすべてのPRにBackport to Gutenberg RCラベルが付いていることを確認してください。
グーテンベルクリポジトリのローカルクローンで、リリースブランチに切り替えます：git checkout release/X.Y
自動化スクリプトを使用して、マージされたすべてのPRをチェリーピックします：npm run other:cherry-pick “Backport to Gutenberg RC”

RCが公開された後、最終的な安定版リリースの前に、リリースに関連するいくつかのバグが修正され、trunkにコミットされることがあります。安定版リリースにはこれらの修正が自動的に含まれません。これらを含めるのは手動プロセスで、チェリーピッキングと呼ばれます。

リリースマネージャーとして、これらのバグを認識する方法はいくつかあります：

貢献者がクローズされたPRにBackport to Gutenberg RCラベルを追加することがあります。これらのPRを検索するのをRCの最終リリース前に行ってください。
#core-editorのSlackチャンネルで、RCに含める必要があるPRについて通知するダイレクトメッセージやピンを受け取ることがあります。この場合でも、Backport to Gutenberg RCはPRに追加されるべきです。

自動チェリーピッキング

チェリーピッキングプロセスは、グーテンベルクに含まれているnpm run other:cherry-pick "[Insert Label]"スクリプトで自動化できます。コマンドを実行する際にはBackport to Gutenberg RCラベルを使用し、チェリーピッキングが必要なすべてのPRにラベルが付けられていることを確認する必要があります。

PRをチェリーピックするには、グーテンベルクリポジトリをクローン（フォークではなく）し、書き込みアクセス権を持っている必要があります。グーテンベルク開発チームのメンバーのみがこのアクションを実行するための必要な権限を持っています。

グーテンベルクリポジトリをローカル開発環境にクローンしたら、リリースブランチに切り替えます：

git checkout release/X.Y

次に、適切なバックポートラベルを持つすべてのマージされたPRをチェリーピックします：

npm run other:cherry-pick "Backport to Gutenberg RC"

裏で、スクリプトは次のことを行います：

Backport to Gutenberg RCラベルの付いたすべてのPRをチェリーピックします。
リリースマイルストーンに追加します。
リリースブランチにgit pushすべての変更を適用します。
チェリーピックされたことを示すコメントをPRに追加します。
PRからBackport to Gutenberg RCラベルを削除します。

プロセスのスクリーンショットは次のとおりです：

自動チェリーピッキング

手動チェリーピッキング

チェリーピッキングを1つずつ、1ステップずつ処理する必要がある場合は、この手順を手動で実行できます。対応するリリースブランチをチェックアウトした後：

1. 各PRをgit cherry-pick [SHA]を使用して（時系列順に）チェリーピックします。
2. 完了したら、git pushを使用して変更をGitHubにプッシュします。
3. Backport to Gutenberg RCラベルを削除し、すべてのチェリーピックされたPRのマイルストーンを現在のリリースに更新します。

プルリクエストの[SHA]を見つけるには、PRを開き、「[Username]マージコミット[SHA]をtrunkに統合しました」というメッセージが最後に表示されます。

手動チェリーピッキング

チェリーピックされた修正が安定版リリースが公開される前に別のリリース候補を必要とする場合は、上記の手順に従って1つを作成します。他の貢献者に#core-editorのSlackチャンネルで新しいリリース候補がリリースされたことを知らせてください。

リリースの公開

クイックリファレンス

リリースドラフトで「リリースを公開」ボタンを押します。
安定版を公開する場合は、グーテンベルクリリース、グーテンベルクコア、またはWordPressコアチームのメンバーから新しいプラグインバージョンをWordPress.orgプラグインリポジトリ（SVN）にアップロードするための承認を得ます。
アップロードが完了したら、最新バージョンがWordPressプラグインダッシュボードからダウンロードおよび更新できることを確認します。

変更履歴の形状に満足したら、「リリースを公開」ボタンを押します。

ボタンの上のチェックボックスを変更する必要はありません。RCを公開する場合、「プレリリースとして設定」が自動的に選択され、安定版を公開する場合は「最新のリリースとして設定」が選択されます。

RCのためのリリース公開チェックボックス

リリースを公開すると、バージョンのgitタグが作成され、リリースが公開され、別のGHAワークフローがトリガーされ、2つの目的があります：

1. 編集したリリースノートを使用してchangelog.txtを更新し、
2. 新しいプラグインバージョンをWordPress.orgプラグインリポジトリ（SVN）にアップロードします（安定版をリリースする場合のみ）。

最後のステップは、グーテンベルクリリース、グーテンベルクコア、またはWordPressコアチームのメンバーによる承認が必要です。これらのチームは、リリースが承認される準備が整ったときに通知メールを受け取りますが、時間が重要な場合は、#core-editor Slackチャンネルで尋ねたり、グーテンベルクリリースチームにピンを送信してプロセスを加速することができます。リリースプロセスを開始する前に、誰かが承認の準備ができていることを確認することをお勧めします。新しいバージョンの「WordPress.orgプラグインリポジトリにグーテンベルクプラグインをアップロード」ワークフローを見つけて、承認を受けてください。

承認されると、新しいグーテンベルクバージョンが世界中のWordPressユーザーに利用可能になります。アップロードが完了したら、最新バージョンがWordPressプラグインダッシュボードからダウンロードおよび更新できることを確認します。

最後のステップは、make.wordpress.org/coreにリリース投稿を書くことです。そのためのヒントは以下にあります。

リリースのトラブルシューティング

プラグインがWordPress.orgプラグインディレクトリに公開されましたが、ワークフローが失敗しました。
これは時折発生します。例えばこれを参照してください。

次のことを確認することが重要です：

ディレクトリからのプラグインが期待通りに動作すること
ZIPの内容（ダウンロードを参照）に明らかな欠落がないこと
グーテンベルクSVNリポジトリに2つの新しいコミットがあること（ログを参照）：
- trunkフォルダーには「バージョンX.Y.Zをコミットしています」と表示されるべきです。
- tags/X.Y.Zフォルダーにはtrunkと同じ内容が含まれ、最新のコミットは「バージョンX.Y.Zをタグ付けしています」となります。

おそらく、タグフォルダーを作成できなかったのです。これは既知の問題であり、手動で修正できます。

SVN_USERNAME、SVN_PASSWORD、およびVERSIONを適切な値に置き換えるか、最初にグローバル環境変数として設定してください：


# リポジトリのチェックアウト
svn checkout https://plugins.svn.wordpress.org/gutenberg/trunk --username "$SVN_USERNAME" --password "$SVN_PASSWORD" gutenberg-svn
# ローカルフォルダーに移動
cd gutenberg-svn
# すでにローカルにリポジトリがある場合
# チェックアウトしていない場合は、更新されていることを確認
# svn up .
# 現在のトランクを新しいタグフォルダーにコピー
svn copy https://plugins.svn.wordpress.org/gutenberg/trunk https://plugins.svn.wordpress.org/gutenberg/tags/$VERSION -m 'バージョン$VERSIONをタグ付け' --no-auth-cache --non-interactive  --username "$SVN_USERNAME" --password "$SVN_PASSWORD"

何か助けが必要な場合は、周りに聞いてください。

リリースの文書化

リリースの文書化は、リリースマネージャーがグーテンベルク開発チームのメンバーの助けを借りて行います。このプロセスは、RCと安定版リリースの間のタイムラインに従う必要があるため、関与する人数と調整が必要なため、一連の順次ステップで構成されています。安定したグーテンベルクリリースは、水曜日に、最初のRCの1週間後に行われます。

タイムライン

1. リリース投稿用のGoogleドキュメントテンプレートのコピーを作成します – 水曜日から金曜日
2. リリースのハイライトを選択します – 金曜日から月曜日
3. ハイライトが確定したら、デザインチームにリリースアセット（画像、動画）をリクエストします –金曜日から月曜日
4. リリース投稿をドラフトし、ピアレビューをリクエストします – 月曜日から水曜日
5. 安定版がリリースされた後に投稿を公開します – 水曜日

リリースのハイライトを選択

変更履歴が整理されたら、次のステップはリリース投稿で強調表示するいくつかの変更を選択することです。これらのハイライトは通常、新機能や強化に焦点を当てており、パフォーマンスやアクセシビリティのものも含まれますが、重要なAPIの変更や重大なバグ修正も含まれることがあります。

グーテンベルクの大規模な範囲と、各マイルストーンでマージされるPRの数が多いため、強調表示する価値のある影響力のある変更を見落とすことは珍しくありません。このため、このステップはリリースマネージャーと他のグーテンベルク開発チームメンバーとの共同作業です。何を選ぶべきかわからない場合は、チームの他のメンバーに助けを求めてください。

リリースアセットのリクエスト

新しいWordPressリリースのハイライトを特定した後、リリースマネージャーはデザインチームに視覚的アセットをリクエストします。リクエストは#designのSlackチャンネルで行われ、15.8の例の投稿はこちらで見つけることができます。アセットは特定のリリースに割り当てられたGoogleドライブフォルダーに提供されます。

WordPressリリースの視覚的アセットを作成する際は、アニメーション（動画またはGIF）や静止画像を使用してハイライトを紹介します。以前のリリース投稿をガイドとして使用し、アニメーションはワークフローを示すのに適している一方で、より直接的なハイライトは画像で示すことができます。アセットを作成する際は、著作権で保護された素材を使用せず、ブラウザキャンバスに表示されるブラウザプラグインを無効にしてください。

リリース投稿のドラフト作成

リリースマネージャーは、Googleドキュメントテンプレートに基づいてリリース投稿のドラフトを作成する責任があります。ただし、リリース投稿の内容の性質上、事前に合意があれば、責任を分担し、他のチームメンバーに委任することができます。ドラフトが完成したら、ピアレビューをリクエストします。

リリース投稿の公開

投稿内容が準備できたら、make.wordpress.org/coreに投稿する権限を持つ著者が新しいドラフトを作成し、内容をインポートします。投稿には次のタグを含める必要があります：

著者は投稿の公開プレビューを有効にし、最終的なピアレビューをリクエストする必要があります。これはmake/core投稿ガイドラインによって奨励されています。

最後に、投稿は安定版がリリースされ、WordPress.orgで利用可能になった後に公開されるべきです。これにより、外部メディアがリリースを反響させ、拡大するのに役立ちます。

マイナーリリースの作成

時折、プラグインのマイナーリリース（すなわちX.Y.Z）を作成する必要があります。これは通常、悪いリグレッションやバグの修正を迅速に行うために行われます。Backport to Gutenberg Minor Releaseは通常、マイナーリリースに含める必要があるPRを特定するために使用されますが、リリースコーディネーターとして、Slackを通じてより非公式に通知されることもあります。それでも、すべての関連PRが正しいラベルを持っていることを確認することは良いことです。

次のプロセスを進める際には、そのようなマイナーリリースは独自のブランチとして作成されるのではなく（例：release/12.5.0）、単にタグであることを考慮する価値があります。

マイナーリリースの方法は、メインプラグインリリースプロセス（上記を参照）とほぼ同じですが、いくつかの顕著な例外があります。進む前に全体のガイドを読むことを確認してください。

リリースブランチの更新

マイナーリリースには、特定のコミットのみを含める必要があります。これを行うには、以前のメジャー安定（すなわち非RC）リリースブランチ（例：release/12.5）をローカルでチェックアウトし、必要なコミットをそのブランチにチェリーピックします。

新しいバージョンのRCがすでに存在する場合、同じコミットをそれぞれのリリースブランチにチェリーピックする必要があります。そうしないと、自動的には含まれません。例えば：新しいマイナーリリースを12.5のためにリリースしようとしていて、release/12.5にチェリーピックしたばかりですが、12.6.0-rc.1がすでに出ている場合、同じコミットをrelease/12.6ブランチにチェリーピックする必要があります。そうしないと、12.6の後続のリリースには含まれません！通常、このプロセスは次のリリースのリリースコーディネーターと調整するのが最善です。

チェリーピッキングプロセスは、npm run cherry-pickスクリプトで自動化できますが、スクリプトを実行する際にはBackport to Gutenberg Minor Releaseラベルを使用することを確認してください。

また、含まれるすべてのPRがマイナーリリースに基づくGitHubマイルストーンに割り当てられていることを確認する必要があります。PRがマージされると、自動的に次の安定リリースのマイルストーンが割り当てられます。したがって、GitHubの各PRを再度確認し、マイルストーンを再割り当てする必要があります。

たとえば、12.5.4バージョンをリリースする場合、そのリリースに選ばれたすべてのPRは12.6マイルストーンから割り当てを解除し、12.5マイルストーンに割り当てる必要があります。

チェリーピッキングが完了したら、PRからBackport to Gutenberg Minor Releaseラベルを削除することもできます。

安定版リリースブランチが整い、PRに正しいマイルストーンが割り当てられたら、ブランチをGitHubにプッシュし、GitHubウェブサイトGUIを使用してリリースプロセスを続行できます。

マイナーリリースの実行

プラグインリリースのためのワークフロードロップダウン

グーテンベルクのGitHubリポジトリのアクションタブに移動し、「Build Gutenberg Plugin Zip」アクションを見つけます。現在のプラグインリリースバージョンに関する情報に基づいて、次のアクションを慎重に選択する必要があります：

前のリリースバージョンが*安定（X.Y.Z – 例：12.5.0、12.5.1など）である場合、Use workflow fromフィールドはtrunkのままにし、テキスト入力フィールドにstableを指定します。ワークフローは自動的にマイナーリリースを作成し、必要に応じてx.y.(z+1)が増加します。

前のリリースがRC（例：X.Y.0-rc.1）である場合、リリースを作成する際に安定版のリリースブランチ（例：12.5.0）を手動で選択する必要があります。これを行わないと、ワークフローは次のメジャー安定*バージョン（例：12.6.0）をリリースしてしまいます。これは望ましくありません。

これを行うには、ワークフローを実行する際に、Use workflow fromドロップダウンから適切なrelease/ブランチを選択し、テキスト入力フィールドにstableを指定します。

以前の安定版リリースのためのマイナーリリースの作成

最近の安定版リリースが公開された後でも、任意のリリースブランチのマイナーリリースを作成することが可能です。これは、ユーザーへの更新を提供する柔軟性を高めるために、任意の以前のリリースブランチに対して行うことができます。過去には、ユーザーは次の安定版リリースを待たなければならず、数日かかる可能性がありました。現在、修正は必要に応じて以前のリリースブランチに迅速に出荷できます。

プロセスは、RCがすでに出ている場合に文書化されたものと同じです：以前のリリースブランチを選択し、stableを入力し、「ワークフローを実行」をクリックします。リリースは、グーテンベルクのGitHubリリースページとWordPressコアリポジトリSVNにtagとして公開されます。SVN trunkディレクトリは変更されません。

重要： 「Build Plugin Zip」ワークフローによって作成されたドラフトを公開する際は、「最後のリリースとして設定」チェックボックスをオフのままにしてください。誤ってチェックを入れた場合、「WordPress.orgプラグインにグーテンベルクプラグインをアップロード」ワークフローは、タグとして正しくアップロードされます（trunkバージョンを置き換えません）が、プラグインがどのように出荷されるべきかを決定するためにいくつかのバージョン算術を実行しますが、GitHubの状態を修正する必要があります。正しいリリースをリリースページでlatestとして設定してください！

トラブルシューティング

リリースドラフトが作成されましたが、空であるかエラーメッセージが含まれています。
正しいマイルストーンをチェリーピックしたPRに割り当てるのを忘れると、変更ログが期待通りに生成されない可能性があります。

変更ログに表示されるPRがリリースブランチにチェリーピックされたPRと一致することを常に手動で確認することが重要です。

さらに、リリースに単一のPRのみが含まれている場合、PRを正しいマイルストーンに割り当てないと、変更ログを生成する際にエラーが表示されます。この場合、リリースノートを編集して、欠落しているPRの詳細を含めることができます（以前のリリースからフォーマットを手動でコピーします）。

何らかの理由でマイルストーンが閉じられている場合、リリースの目的で再オープンすることができます。

ドラフトリリースには1つのアセットファイルしか含まれていません。他のリリースにはx3があります。
これは予想通りです。ドラフトリリースにはプラグインのzipファイルのみが含まれます。リリースが公開されると、残りのアセットが生成され、リリースに追加されます。
WordPress.orgにポイントリリースを公開する必要がありますか？
はい。この方法は、メインプラグインリリースプロセスと同じです。グーテンベルクコアチームのメンバーがリリースワークフローを承認する必要があります。
リリースプロセスがトランクブランチにバージョンバンプコミットをチェリーピックするのに失敗しました。
まず、trunkの最新のコミットにバージョンバンプコミットが含まれていないことを確認して、ステップが失敗したことを確認します。次に、リリースブランチでバージョンバンプコミットを元に戻します – git revert --no-edit {commitHash}。最後に、変更をプッシュしてリリースプロセスを再開します。

NPMへのパッケージリリースとWordPressコアの更新

グーテンベルクリポジトリは、WordPress SVNリポジトリのブランチ戦略に従って、すべての主要なWordPressリリースに対応しています。それに加えて、npmの公開ワークフローを制御するための2つの特別なブランチも含まれています：

wp/latestブランチは、latest配布タグでnpmに公開されたパッケージと同じバージョンのパッケージを含んでいます。ここでの目標は、このブランチを最新のグーテンベルクプラグインリリースと同期させることであり、唯一の例外は計画外のバグ修正リリースです。
wp/nextブランチは、next配布タグでnpmに公開されたパッケージと同じバージョンのパッケージを含んでいます。常にtrunkブランチと同期されます。プロジェクトは、開発またはテスト目的のみにこれらのパッケージを使用する必要があります。
特定のWordPressの主要リリース（その後のマイナーインクリメントを含む）をターゲットにしたグーテンベルクブランチwp/X.Y（例：wp/6.2）が、次の主要なWordPressリリースに含まれる最後のリリースの計画後に、現在のグーテンベルクプラグインリリースブランチrelease/X.Y（例：release/15.1）に基づいて作成されます。

リリースタイプとそのスケジュール：

グーテンベルクプラグインの同期（latest配布タグ） – 公開は、2週間ごとに新しく作成されたrelease/X.Y（例：release/12.8）ブランチのRC1バージョンのグーテンベルクプラグインに基づいて自動的に行われます。
WordPressリリース（wp-X.Y配布タグ、例：wp-6.2） – 公開はwp/X.Y（例：wp/6.2）ブランチからの要求に応じてトリガーされます。WordPressの主要リリースサイクルのポイント（ベータ1の直前）に到達したとき、グーテンベルクリポジトリからWordPressコアにコミットをチェリーピックするだけになると、wp/X.Yブランチ（release/X.Yブランチから作成、例：release/15.1）を使用して、wp-X.Y配布タグでnpmを公開します。古いブランチを使用して、バグやセキュリティ修正を対応する古いバージョンのWordPressコアにバックポートすることも可能です。
開発リリース（next配布タグ） – 今後の変更をテストする必要がある場合、いつでも開発リリースを実行することも可能です。

また、スタンドアロンバグ修正パッケージリリースを随時実行するオプションもあります。これは、定期的なサイクルの外で公開する必要がある重要なバグ修正やセキュリティリリースのみに予約されるべきです。

グーテンベルクプラグインの同期

各グーテンベルクプラグインリリースに対して、WordPressパッケージの更新版をnpmに公開します。これは、グーテンベルクプラグインのリリースを処理するリリースツールによって自動化されています。成功したRC1リリースはnpm公開ジョブをトリガーし、これにはグーテンベルクコアチームのメンバーによる承認が必要です。新しいバージョンの「グーテンベルクプラグインZipをビルド」ワークフローを見つけて、承認を受けてください。

私たちは意図的に、グーテンベルクRC1リリースの時点で、グーテンベルクリリースrelease/X.Y（例：release/12.7）ブランチからのコンテンツでwp/latestブランチを更新します。これは、wp/latestブランチがグーテンベルクプラグインの最新バージョンにできるだけ近くなるようにするためです。また、trunkコミットをpackage.jsonおよびCHANGELOG.mdファイルに公開中に適用された更新とバックポートする際の競合の可能性を実質的に排除します。過去には、通常のグーテンベルクリリースの1週間後にnpm公開を行う際に、多くの問題がありました。npmに新しいパッケージバージョンを公開する際には、将来のバグ修正やセキュリティリリースを考慮して、少なくともminorバージョンバンプを選択します。

裏では、すべてのステップは./bin/plugin/cli.js npm-latestコマンドを介して自動化されています。記録のために、手動プロセスは次のステップに非常に近いものになります：

1. WordPress trunkブランチが拡張のためにオープンであることを確認します。
2. 最後に公開されたグーテンベルクリリースブランチをgit fetchで取得します。
3. wp/latestブランチをチェックアウトします。
4. 現在のブランチからすべてのファイルを削除します：git rm -r .。
5. リリースブランチからすべてのファイルをチェックアウトします：git checkout release/x.x -- .。
6. すべての変更をwp/latestブランチにgit commit -m "Merge changes published in the Gutenberg plugin vX.X release"でコミットし、リポジトリにプッシュします。
7. 新しい公開バージョンで計算されたCHANGELOG.mdパッケージのファイルを更新し、wp/latestブランチにコミットします。パッケージバージョンがこの形式major.minor.patchを使用して書かれていると仮定し、少なくともminorバージョンバンプが適用されることを確認してください。たとえば、リリースされるパッケージのCHANGELOGが次の未リリースバージョンが5.6.1であることを示している場合、5.7.0をminorバージョンの場合のバージョンとして選択します。これは、マイナーWordPressリリースに対してバグ修正が必要な場合にパッチバージョン番号が予約されるべきであるため重要です（以下を参照）。
8. コンソール経由でnpmにログインします：npm login。2FAが有効になっていることを確認してください。
9. wp/latestブランチから、npm ciでnpm依存関係をインストールします。
10. スクリプトnpx lerna publish --no-privateを実行します。
- 各パッケージの選択するバージョン番号を尋ねられたとき、更新されたCHANGELOGファイルの値を選択します。
- 一時的なパスワード（OTP）を数回尋ねられます。これは、使用している2FA認証アプリからのコードです。リリースされるパッケージの数に応じて、すべてのパッケージがリリースされる前に期限切れになることがあるため、複数のOTPを求められることがあります。
- 公開プロセスが不完全な場合（タイムアウトしたり、悪いOTPが導入されたりした場合）、npx lerna publish from-packageを介して再開できます。
11. 最後に、npmパッケージが公開されたので、lernaによって作成されたコミット（「公開」とCHANGELOGの更新）をグーテンベルクのtrunkブランチにチェリーピックします。

WordPressリリース

バグやセキュリティ修正をWordPressコアにバックポートする必要がある場合、次のワークフローが必要です。これはいくつかのユースケースで発生する可能性があります：

WordPressリリースサイクルのbetaおよびRC期間中に、リリース用のwp/X.Y（例：wp/5.7）ブランチがすでに存在する場合。
WordPressのマイナーリリースおよびWordPressのセキュリティリリース（例：5.1.1）。
1. 関連するWordPressの主要ブランチをチェックアウトします（マイナーリリースが5.2.1の場合、wp/5.2をチェックアウトします）。
2. そのブランチからフィーチャーブランチを作成し、必要なバグ修正のマージコミットをチェリーピックします。チェリーピックプロセスは、npm run other:cherry-pickスクリプトで自動化できます。
3. このブランチから、上記で使用したWordPressの主要ブランチをターゲットにしたプルリクエストを作成します。
4. コミットの履歴を保持するために「リベースしてマージ」ボタンを使用してプルリクエストをマージします。

これで、wp/X.Yブランチはnpmパッケージの公開の準備が整いました。プロセスを開始するには、グーテンベルクのGitHubリポジトリのアクションタブに移動し、「npmパッケージを公開」アクションを見つけます。「このワークフローにはworkflow_dispatchイベントトリガーがあります。」という青いバナーに注意し、その右側の「ワークフローを実行」ドロップダウンを展開します。

npm公開のためのワークフロードロップダウンを実行

WordPressの主要リリース用にnpmにパッケージを公開するには、ワークフローを実行するブランチとしてtrunkを選択します（これは、ワークフローを実行するために使用されるスクリプトがトランクブランチから来ることを意味しますが、パッケージ自体はリリースブランチから公開されます。正しい「リリースタイプ」が下で選択されている限り）、次に「リリースタイプ」ドロップダウンからwpを選択し、「WordPressの主要リリース」入力フィールドにX.Y（例：5.2）を入力します。最後に、緑の「ワークフローを実行」ボタンを押します。これによりnpm公開ジョブがトリガーされ、これにはグーテンベルクコアチームのメンバーによる承認が必要です。現在の公開のための「npmパッケージを公開」アクションを見つけて、承認を受けてください。

記録のために、手動プロセスは次のようになります：

1. 以前に使用したWordPressブランチをチェックアウトします（例：wp/5.2）。
2. git pull。
3. パッケージリリースプロセスでさらに詳しく見て、npx lerna publish patch --no-private --dist-tag wp-5.2コマンドを実行しますが、各パッケージの選択するバージョン番号を尋ねられたとき（パッケージバージョンがこの形式major.minor.patchを使用して書かれていると仮定し）、patchバージョン番号のみをバンプすることを確認してください。たとえば、このWordPressブランチの最後に公開されたパッケージバージョンが5.6.0であった場合、5.6.1をバージョンとして選択します。

注意： WordPress 5.0およびWordPress 5.1の場合、異なるリリースプロセスが使用されました。これは、これら2つのリリースをターゲットにしたnpmパッケージバージョンを選択する際に、次のpatchバージョン番号を使用できないことを意味します。すでに使用されている可能性があります。これらには「メタデータ」修飾子を使用する必要があります。たとえば、このWordPressブランチの最後に公開されたパッケージバージョンが5.6.1であった場合、5.6.1+patch.1をバージョンとして選択します。

1. オプションで、公開されたパッケージのCHANGELOG.mdファイルを新しいリリースバージョンで更新し、対応するブランチにコミットします（例：wp/5.2）。
2. 変更ログの更新コミットがある場合は、trunkブランチのグーテンベルクにチェリーピックします。

これで、npmパッケージは準備が整い、パッチを作成して対応するWordPress SVNブランチにコミットできます。

スタンドアロンバグ修正パッケージリリース

パッケージにバグ修正やセキュリティリリースが必要な場合、通常のリリースサイクルの外でnpmに公開する必要があるときに、次のワークフローが必要です。

注意：trunkおよびwp/latestブランチは制限されており、グーテンベルクコアチームのみがpushedできます。

リポジトリtrunkブランチからwp/latestにポートする必要があるプルリクエストのコミットハッシュを特定します。


ターミナルを開き、次の手順を実行します：  
- 1*.* `````git checkout trunk

2. git pull
3. git checkout wp/latest
4. git pull

コミットをポートする前に、wp/latestブランチに公開待ちのパッケージがないことを確認します：

1. git checkout wp/latest
2. npx lerna updated

次に、trunkからwp/latestにコミットをチェリーピックします。コミットがプルリクエストマージコミットであった場合は-m 1 commithashを使用します：

1. git cherry-pick -m 1 cb150a2
2. git push


- 1*.* `````git checkout wp/latest

2. npx lerna updated
> 例
>
> `````shell

npx lerna updated
@wordpress/e2e-tests
@wordpress/jest-preset-default
@wordpress/scripts
lerna success found 3 packages ready to publish
`````

現在のCHANGELOG.mdファイルにリストされているバージョンを確認し、パッケージのコミット履歴を確認します。たとえば、@wordpress/scriptsを見て、「chore(release): publish」や「Update changelogs」コミットを探して、最近のバージョンバンプを特定し、最も最近のリリース以降に発生した変更を特定するのに役立ちます。

注意：各パッケージの現在のバージョンが最新でない場合、以前にリリースされたバージョンを更新することが評価されます。

これで、wp/latestブランチはnpmパッケージの公開の準備が整いました。プロセスを開始するには、グーテンベルクのGitHubリポジトリのアクションタブに移動し、「npmパッケージを公開」アクションを見つけます。「このワークフローにはworkflow_dispatchイベントトリガーがあります。」という青いバナーに注意し、その右側の「ワークフローを実行」ドロップダウンを展開します。

npm公開のためのワークフロードロップダウンを実行

バグ修正を含むnpmにパッケージを公開するには、「リリースタイプ」ドロップダウンからbugfixを選択し、「WordPressの主要リリース」入力フィールドを空のままにします。最後に、緑の「ワークフローを実行」ボタンを押します。これによりnpm公開ジョブがトリガーされ、これにはグーテンベルクコアチームのメンバーによる承認が必要です。現在の公開のための「npmパッケージを公開」アクションを見つけて、承認を受けてください。

裏では、残りのプロセスは./bin/plugin/cli.js npm-bugfixコマンドで自動化されています。記録のために、手動プロセスは次のステップに非常に近いものになります：

1. wp/latestブランチをチェックアウトします。
2. 新しい公開バージョンで計算されたCHANGELOG.mdパッケージのファイルを更新し、wp/latestブランチにコミットします。
3. コンソール経由でnpmにログインします：npm login。2FAが有効になっていることを確認してください。
4. wp/latestブランチから、npm ciでnpm依存関係をインストールします。
5. スクリプトnpx lerna publish --no-privateを実行します。
- 各パッケージの選択するバージョン番号を尋ねられたとき、更新されたCHANGELOGファイルの値を選択します。
- 一時的なパスワード（OTP）を数回尋ねられます。これは、使用している2FA認証アプリからのコードです。リリースされるパッケージの数に応じて、すべてのパッケージがリリースされる前に期限切れになることがあるため、複数のOTPを求められることがあります。
- 公開プロセスが不完全な場合（タイムアウトしたり、悪いOTPが導入されたりした場合）、npx lerna publish from-packageを介して再開できます。
6. 最後に、npmパッケージが公開されたので、lernaによって作成されたコミット（「公開」とCHANGELOGの更新）をグーテンベルクのtrunkブランチにチェリーピックします。

開発リリース

グーテンベルクプラグインの同期セクションで述べたように、パッケージの公開はwp/latestブランチから2週間ごとに行われます。また、trunkブランチに存在する今後の変更をテストするために、いつでも開発リリースを使用することも可能です。私たちは、npmガイドラインに従ってコードベースの将来のバージョンを消費することを可能にするパッケージ配布タグを利用しています：

デフォルトでは、npmはlatestタグを使用してパッケージの現在のバージョンを識別し、npm install <pkg>（@<version>や@<tag>の指定なし）はlatestタグをインストールします。通常、プロジェクトは安定したリリースバージョンにはlatestタグのみを使用し、プレリリースなどの不安定なバージョンには他のタグを使用します。
私たちの場合、コードにはnext配布タグを使用します。このパッケージのそのようなバージョンをインストールしたい開発者は、次のように入力する必要があります：

npm install @wordpress/components@next

npmパッケージの開発バージョンの公開プロセスを開始するには、グーテンベルクのGitHubリポジトリのアクションタブに移動し、「npmパッケージを公開」アクションを見つけます。「このワークフローにはworkflow_dispatchイベントトリガーがあります。」という青いバナーに注意し、その右側の「ワークフローを実行」ドロップダウンを展開します。

npm公開のためのワークフロードロップダウンを実行

npmに開発パッケージを公開するには、「リリースタイプ」ドロップダウンからdevelopmentを選択し、「WordPressの主要リリース」入力フィールドを空のままにします。最後に、緑の「ワークフローを実行」ボタンを押します。これによりnpm公開ジョブがトリガーされ、これにはグーテンベルクコアチームのメンバーによる承認が必要です。現在の公開のための「npmパッケージを公開」アクションを見つけて、承認を受けてください。

裏では、リリースプロセスは./bin/plugin/cli.js npm-nextコマンドを介して完全に自動化されています。これにより、wp/nextブランチがグーテンベルクプラグインのために作成された最新のリリースブランチ（release/X.Y）と同期されます。パッケージのバージョン管理の衝突を避けるために、常に最新のコミットのshaを含めます。たとえば、@wordpress/[email protected]。