ブロックエディター メジャーリリース時のリリースプロセス
Topics
このガイドでは、WordPress のメジャーリリースにおけるエディター (Gutenberg) の扱い方を明らかにします。これは随時更新されるドキュメントです。フィードバックやアップデートをお寄せください。
リリースプロセスでの役割
WordPress の各メジャーバージョンのエディターリリースプロセスを管理するには、チームが必要です。主要な役割とその責任については、以下をご覧ください。
タイムラインのクリックリファレンス
これは時間が重要なタスクで、いつ完了する必要があるかを順に並べたリストです。各タスクの詳細については、このドキュメントの後半で説明します。
ベータ1の2ヵ月前
- GitHub にリリースプロジェクトボードを設置する
- 実験的 API を精査する
- コアに手動で追加する必要がある PHP の変更について、概要の issue を作成する
ベータ1の1ヵ月前
- 最新の Gutenberg パッケージと PHP の変更で Trunk をアップデートする
- 開発者ノートのためのイシュートラッカーを作成します。開発者ノートは RC1までに公開されるはずであり、そのために十分な時間が必要です
ベータ1から最後の RC までの間
- 最近のバグレポートやラベルのない issue をトリアージし、重大なリグレッションを発見する
- 重要なリグレッションをすべて修正し、リリースに関連するバグを可能な限り修正する
各ベータ/RC リリースの前の週
- Backport to WP Beta/RC とラベル付け、マージされたすべてのプルリクエストに目を通し、それらを含めても問題がないことを確認する
- 同じラベルのプルリクエストをレビューする
- パッケージアップデートとコアパッチプロセスを開始する
最初のメジャーリリースベータ版の前の計画
各リリースサイクルの開始時には、WordPress のメジャーリリースに至るまでの主要なマイルストーンを示す計画に関する投稿が公開されます (6.3の例)。この投稿には、すべてのベータ版と RC 版のリリースの期限と、すべてのリリースチームメンバーの名前が含まれます。
最後のエディターのリリースを計画し、締め切りを伝える
Gutenberg のリリースは隔週で行われるため、どの Gutenberg のリリースがベータ1に最も近い時期に予定されているかを判断し、必要に応じてプラグインのリリース日をベータ1に合わせて再調整できます。
理想的には、この最後 の Gutenberg RC はベータ1の4～5日前にリリースされるべきです。このスケジュールであれば、チームが npm パッケージを公開し、コアでバージョンを更新できるようにしながら、バグを特定して修正するために十分な時間が与えられます。
貢献者がエディターの新機能をメジャーリリースに含めたい場合、この最後の Gutenberg RC に含める必要があります。そのため、最終的な Gutenberg のリリースが決まったら、#core-editor Slack チャンネルや、毎週のエディターチャットミーティングで共有し、貢献者が適切に準備できるようにしましょう。
ロードマップに関する投稿
ロードマップの投稿は、現在のメジャーリリース (6.3の例) で予定されている機能、拡張、バグ修正を特定します。このリソースの作成は、リリースリードと貢献者による共同作業です。
エディターテックやトリアージリードであれば、この投稿をよく理解しておく必要があります。これは、リリースに何を含めるべきかを知るための優れたリソースです。また、報告されたどの問題がリリースに関連していて、どれをプロジェクトボードに追加する必要があるのかを判断するうえでも非常に役立ちます。詳細については以下をご覧ください。
プロジェクトボードの管理
Gutenberg の GitHub リポジトリにメジャーリリース用の「プロジェクトボード」を作成することがベストプラクティスとなっています。このボードはタスクの調整に役立ち、リリースに関連するすべての issue とプルリクエストを含む必要があります。
プロジェクトボードの設定方法
WordPress 6.3から、プロジェクトボードの設定に役立つテンプレートが作成されました。
- テンプレートに移動します: WordPress (X.X) Editor Tasks
- 新しいボードを作成するために「Use this template」ボタンをクリックします
- ボードのタイトルを「WordPress X.X Editor Tasks」の形式で更新します
- 「Punted to 6.X.1」と「Punted to 6.Y」のカラムタイトルを更新します
- Gutenberg Projects ページに移動し、「Link Project」をクリックして新しく作成したプロジェクトを Gutenberg リポジトリにリンクします。
テンプレートには以下のカラムが含まれます:
- Triage – すべての新しい issue は、このカラムのボードに追加されます。リリースリードは、必要に応じてその issue が「Todo」、「In discussion / Needs decision」、または他のカラムに属するかどうかを決定します。リードの間で一般的な合意が得られた場合は、issue をボードから完全に削除することもできます。
- In Discussion / Needs Decision – リリースに向けてチームが検討するためにさらに時間が必要な issue やプルリクエストが含まれます。結論が出ない理由としては、次のようなことが考えられます。
- 問題は重大であるが、再現できなかったため、問題が発生する具体的な条件を理解するために、より多くの情報を待つ必要がある。
- その問題がリグレッションなのかそうでないのか、あるいはバグなのか期待された動作なのかを明確にする必要がある
- その問題は複雑なテスト設定を必要とし、その再現には時間がかかる。この場合、issue を見付けた時点で、それをテストするために何をしなければならないかをコメントとして書くべきです。こうすることで、他の人がテストを手伝いやすくなります。必要であれば、「needs-testing」ラベルも追加する必要があるかもしれません。issue をテストし問題を確認できたら、「Todo」列に移動してください。
- Todo – チームがリリースまでに修正する必要があると判断したものの、プルリクエストが関連付けられていない issue が含まれます。
- In Progress – チームがリリースまでに修正する必要があると判断し、プルリクエストが関連付けられている issue が含まれます。
- Needs Review – 「In Progress」カラムの issue に関連するプルリクエストで、まだマージされておらず、レビューが必要なものが含まれます。
- Needs Core Commit – エディターテックリードが、追加のコアコミットが必要であると決定したプルリクエストが含まれます。
- Done – 完了した issue とプルリクエストが含まれます。
- Punted to 6.X.1 – チームが次のマイナーリリースに持ち越すべきと判断した issue とプルリクエストが含まれます。
- Punted to 6.Y – チームが次のメジャーリリースに持ち越すべきと判断した issue やプルリクエストが含まれます。
プロジェクトボードを作成したら、前のリリースのプロジェクトボードを確認し、前のリリースから持ち越された issue やプルリクエストをすべて移行してください。すべてを移行したら、古いプロジェクトボードからそれぞれ削除してください。
「punting」はアメリカンフットボールに由来するスポーツの比喩であることに注意してください。何かを punt した場合、現在のリリースにそれを含めないことを決定し、次のマイナーまたはメジャーリリースに「punt」されます。
プロジェクト・ボードを常に最新の状態に保つ
プロジェクトボードは、ミーティングで参照され人々がブックマークする場所となるため、情報を最新の状態に保ち、他の人にとって役立つようにすることが重要です。以下のアクションが推奨されます。分割することもできます:
- リリースリードや Gutenberg トリアージチームのメンバーは、定期的に新しい Gutenberg の issue を確認し、現在のリリースに関連するものを「トリアージ」カラムのプロジェクトに追加してください。
- 「Todo」カラムの項目を優先度順にソートしてください。より多くの人に見てもらえるよう、優先度の高い項目を一番上に置いてください。
Regressionラベルの付いた issue は常に一番上に来るようにします。 - issue にプルリクエストが関連付けられたら、その issue を「In Progress」カラムに移動し、プルリクエストを「In Review」カラムに追加してください。
- ボード上の issue に関連付けられているプルリクエストもプロジェクトボードに追加する必要があります。
- すべての issue とプルリクエストに適切なラベルが付けられていることを確認してください。
エディターウィークリーチャットミーティングや #core-editor Slack チャンネルで、プロジェクトボードへのリンクを定期的に共有します。これにより、人々はプロジェクトボードをチェックし、共有する習慣が身に付きます。また、許可を得て貢献者に、重要だと思う issue を「トリアージ」カラムに追加するよう促すこともできます。そこから先はエディタートリアージリードが対応します。
非同期トリアージセッションの開催
ベータ版のリリースサイクル中、#core-editor Slack チャンネルでの毎週のトリアージセッションは中断されます。その代わりに、プロジェクトボード、特に「Triage」と「In Discussion / Needs Decision」カラムを特別に扱う非同期のトリアージセッションが行われます。これらのミーティングにより、エディターテックとトリアージリードは、issue とプルリクエストをどのように優先順位付けし、管理すべきかについて効率的に「投票」できます。
多くの場合、リリースチームはさまざまなタイムゾーンにまたがるメンバーで構成されるため、非同期ミーティングであれば全員が都合の良いときに参加できます。
最初のミーティングのお知らせを #core-editor Slack チャンネルに作成し、各プルリクエストと issue をスレッドに追加します。リードは絵文字を使って投票し、スレッドにコメントを追加できます。
これらのミーティングは、他のすべての貢献者が決定された内容を見ることができるように、公開で行われます。以下は6.3のミーティングの例ですが、必要に応じて自由に変更してください。
ボードからのタスクを割り当てる
「To Do」欄の項目については、リリースのマイルストーンまでに割り当てられる人を見つけることをおすすめします。最も簡単な方法は、#core-editor チャンネルで、その欄のタスクを選んでくれるボランティアを募集することです。ボランティアとして参加できる人がいない場合は、助けが必要な項目に詳しい人を見つけて (ここでは、過去の Gutenberg プルリクエストを確認することも役に立ちます)、その人に引き受けてもらえるか、または他の人に手伝ってもらえるかをたずねる必要があるでしょう。
リリースにとって重要だと思われる issue があるにもかかわらず、誰もその issue を取り上げてない場合は、できるだけ早くエディターテックリードに知らせてください。
どの機能をリリースに含めるべきかを考える
リリースロードマップの投稿と最近の「What’s New」リリース投稿をレビューし、重要な機能を決定します。
リリースロードマップの投稿には、各リリースで最優先とされる機能がリストアップされています。タイムリーで安定した方法でコアに取り込まれるよう、これらに特別な注意を払う必要があります。
Gutenberg のリリース投稿を確認することも良いでしょう。現在取り組んでいるすべての機能や、小さな機能強化、バグ修正などを知ることができます。
特に実験的な機能については、それらに取り組んでいる開発者に連絡し、コアに含める準備ができているかどうかを話し合うことが役立ちます。
追加する機能を決定する
リリースの主な機能以外に、リリース全体を補完するために含めると便利な追加機能が進行中であることがよくあります。これには、前回のメジャーリリースで見落とされた機能だけでなく、単純にマイナーな機能やアップデートが含まれるかもしれません。これらを含めることができるかどうかは、以下のようなさまざまな要因によりますが、これらに限定されるものではありません:
- どのような機能を完成させることが重要か ?
- 各機能の複雑さとリスクは何か ?
- リリースの主な機能をどのように補完するか。
- その機能に積極的に取り組んでいる貢献者はいますか ?
追加すると決めた機能については、必ず GitHub のリリースプロジェクトボードに追加してください。プルリクエストを手伝ったり、元の作成者のブロックを解除したりするなど、これらの機能を前進させるために最善を尽くしてください。
もしあなたが追加したい機能で、積極的に取り組んでいる人がいないものがあれば、#core-editor ミーティングでボランティアを募集してください。もしあなたが、ある機能に取り組むことに適した開発者を知っているなら、その開発者に連絡し、それが可能かどうかたずねることが良いでしょう。彼らができないとしても、できる人を紹介してくれるかもしれません。
機能を削除するときの対処法
どのようなリリースでもそうですが、厳しい決断を迫られることがあります。以下は、効果的なコミュニケーションを行い、必要であればリリースにその機能を含めないという決断を下すための最善のステップです:
- その機能に取り組んでいる人々に、その機能が含まれないリスクがあることをできるだけ早く伝え、それを変更するにはいつまでに何をする必要があるかを明確に示す。
- #core-editor ミーティングでのアップデートと並行して、進捗があった場合やなかった場合のアップデートをリリースチームに伝える。
- 機能の削除が決定された場合、Make Core に最終決定を知らせる記事を書いてください。これは過去のリリースの例です。
これらすべてにおいて重要なことは、すべての関係者 (貢献者、リリースチームのメンバーなど) が適切な準備ができるように、明確でタイムリーなコミュニケーションをとることです。
実験的 API の管理
2023年初頭に private-apis システムが作成されて以来、実験的 API を管理するシステムが変更され、安定していないものや公開 API として利用する予定のないものはすべて非公開となりました。
しかし、Gutenberg にはまだ多くの古い実験的 API が残っており、接頭辞が __experimental であることで見分けることができます。これらは関数、プロパティ、変数であり、コードベースのいたるところにあります。リリースのたびに、これらの API を監査し、安定化の準備ができているかどうかをチェックすることが通例です。ベータフェーズでは名前の変更ができないため、最初のベータ1リリースの前 (理想的には少なくとも2週間前) に安定化を行うことが重要です。
精査する方法
一般的には、以下のような流れになります:
- 以下のスクリプトを使って実験的 API を精査する
- git blame を使って各 API に誰が関わったかを特定する
- 各実験的 API を追跡するために、GitHub で概要の issue を作成し、API を安定化させる必要があるかどうかを決定するために関係者に通知する (6.2の例)。
まず、実験的 API の精査を開始するために使用するスクリプトを次に示します:
レポートや手動で収集した情報から、関連する実験的な API をグループ化し、現在何があるのかを把握できます。そこから git blame を使って、それぞれの API にどの貢献者が関わっているかを把握し、API を安定できるかどうかを確認します。そして GitHub に新しい概要の issue を作成し、各 API のチェックボックスをリストアップすれば、API の安定化に関する決定が行われたかどうかを簡単に確認できます。
開発者ノートの計画と執筆
開発者ノートのベストプラクティスに関するより詳しい情報は、このハンドブックのページをチェックしてください。
開発者ノートが必要なものを知るために、Needs Dev Note というラベルのついたすべてのプルリクエストをチェックできます。個々の投稿を書くことでコミュニティを情報で圧倒してしまうほど、多くのプルリクエストがあることに気付くかもしれません。このような場合、プルリクエストを同じラベルでグループ化し、グループごとに開発者ノートを提案します。
必要な開発者ノートの種類がわかったら、GitHub の issue (以前の例) に計画を詳細に記述します:
- どのような記事が必要か
- 各投稿の重要なセクションは何か
- それぞれの記事にどのようなプルリクエストを入れるべきか
その際、開発者ノートが必要なプルリクエストを持っている人たちに、作業に取り組むよう通知してください。あなたの理想的な仕事は、それぞれのプルリクエストの作成者からのアップデートを取りまとめ、各開発者ノートを共有するタイムラインを計画し、短期間にあまりにも多くの開発者ノートを共有しないようにすることです。適切な間隔と計画を立てるために、目標日を共有することをおすすめします。
開発者ノートは共同作業であり、多くの異なる人々の助けが必要であることに注意してください。これは、あなたが情報を必要としている人の中には、最初の通知を見逃したり、ノートを書く時間がなかったりする人がいることを意味するかもしれません。追加の通知や Slack のダイレクトメールなどの形で、最新情報を入手するためのフォローアップが必要になるかもしれません。各開発者ノートの各セクションを書き終わったら、チェックボックスにチェックを入れて進捗を表示し、他の人が残りの内容を確認できるようにします。
各開発者ノートをまとめる際、特に複数のプルリクエストを1つの開発者ノートにまとめる場合は、レビューのために関係者と投稿を共有して、全員が同じ認識を持つようにしてください。。そこで合意が得られたら、その開発者ノートをメジャーリリースチームの関係者と共有して、最終的なレビューを受けるようにしてください。
一般的なトリアージ管理
定期的なトリアージ
コアリリースの間に数ヵ月が経過するため、GitHub で定期的に (理想的には毎週)、特にラベルのない新しい issue をトリアージすることが重要です。ポイントは、重大かもしれないものを見逃さないことです。
リリース固有のトリアージ
ラベルのない issue をレビューすること以外では、解決すべき重要な issue を見つけるために、メジャーリリース以降に報告されたすべての issue を時間をかけてレビューすることが重要です。これは主にエディタートリアージリードの仕事ですが、他の貢献者に分担させることもできるすばらしいタスクです。
バグがどの程度重大かを判断する
バグレポートを確認し、それがどの程度重大なものかを判断しようとする場合、特定のバグが導入されたバージョンを知ることがさらに重要になります。たとえば、WordPress の多くのコアバージョンで導入されたものの、コメントがあまりないバグを見つけるかもしれません。これは、そのバグが本当に修正すべき重要なものではないという良い兆候です。
最初のベータ版の後は、アルファフェーズでリグレッションを起こした問題のバグ修正のみを含めることができるため、レビューしているバグが WordPress の最新の安定リリースに影響するかどうかを知ることが重要です。影響を判断するために、異なるセットアップで複数のテスト環境を用意する必要があるかもしれません。たとえば、WordPress の現行バージョン、ベータバージョン、Gutenberg の最新バージョンです。また、問題を報告した人をフォローアップして、Gutenberg を使用しているかどうか、使用している場合はどのバージョンかなど、特定の設定に関する詳細な情報を得る必要があるかもしれません。
最初の WordPress ベータリリースの管理
最初のベータ版は非常に重要な期限です
最初のベータ版マイルストーン以降は追加機能や拡張機能を含めることができません。新機能の拡張には例外を設けることができます。これらについてはリリースチームと話し合う必要があり、承認された場合は、機能ごとに「task (blessed)」タイプの Trac チケットを作成する必要があります。これらのタスクに対するすべての機能強化は、RC1よりも前に完了する必要があります。
ベータ1のリリースプロセスを容易にするため、できるだけ早く trunk の更新を開始してください
各リリースの変更の量は非常に多いため、サイクルのできるだけ早い段階でコア trunk に新機能の追加を開始することが役立ちます。これは、コアによって使用される @wordpress npm パッケージを更新することと、Gutenberg の lib フォルダーと phpunit フォルダーから PHP の変更を手動で同期することの両方を意味します。
実験的な機能が誤ってコアに含まれないように、Gutenberg の機能フラグによって管理されていることを確認してください
コアの npm パッケージを安全に更新するには、コアに含める予定のない実験的な Gutenberg 機能を機能フラグから隠す必要があります。この目的のために IS_GUTENBERG_PLUGIN フラグが一般的に使用されます。またはインタラクティビティ API のこの例のように、特定の機能フィルターが使用される場合もあります。
手動で同期する PHP の変更をリストアップする
手動で同期する必要がある lib フォルダーと phpunit フォルダーから、すべての変更に関する概要の issue を作成します。git blame を使用して、それらの変更の作成者を見つけて通知し、それらの変更のコアプルリクエストを作成します。
block-library パッケージ内の PHP ファイルは、npm パッケージにもとづいてコアで自動生成されるため、手動で同期する必要はありません。
ウィークリーベータ版と RC リリースの管理
最初のベータ版の後、リリース候補 (RC) に至るまで毎週ベータ版がリリースされます。この時点では、新しい issue のトリアージ、リリースに含めるプルリクエストのチェリーピック、パッケージとコアパスの更新という3つの主なタスクがあります。
新しい issue のトリアージ
その週を通して、前回のリリース以降に提出された新しい Gutenberg の issue をすべて注意深く監視し、リグレッションが見つかっていないことを確認してください。もしリグレッションを発見した場合は、すぐに「WordPress X.X Editor Tasks」プロジェクトボードの「Triage」欄にその issue を追加し、さらに調査を進めてください。
プロジェクトボードにある issue に対してプルリクエストが提出されたら、その issue に Backport to WP Beta/RC というラベルを追加して、次のベータリリースに何を含めるべきかを追跡できるようにしてください。
プロジェクトボードに追加する必要のある issue を探すこと以外に、特に毎週のスケジュールで行われるベータリリースの場合、ボード上のすべての issue が、解決されるために誰かに割り当てられていることを確認することが重要です。
リリース用プルリクエストのチェリーピックについて
プロジェクトボード上のプルリクエストが完了したら、次のベータ版または RC 版で利用できるように、コアにバックポートする必要があります。次の手順に従ってください:
wp/x.x(正しい WP リリース番号を使用してください) がまだ作成されていない場合は、作成してリモートリポジトリにプッシュしてください。- Backport to WP Beta/RC というラベルがついたプルリクエストをすべてレビューしてください。すべてが期待通りかどうか、プルリクエストがコアリリースに入ることが「リスク」ではないかどうかを確認します。ガイダンスについては、エディターテックリードとコアテックリードに確認してください。
- マージされずにクローズされたプルリクエストからラベルを削除します。そうしないと、自動チェリーピックスクリプトを混乱させることになります。
wp/x.xの形式にもとづいてブランチを作成します。- 各プルリクエストを新しく作成したブランチにチェリーピックします。
- チェリーピックの自動化が
npm run cherry-pickによって利用できます。これは、Backport to WP Beta/RCラベルのついたすべてのマージされたプルリクエストを見つけ、それらをチェリーピックし、関連するプルリクエストに自動的にコメントし、ブランチを GitHub にプッシュするかどうかを尋ねます。第一引数に別のラベルを渡すこともできます。 - 手動で行うこともできます。コミットのハッシュは GitHub のプルリクエストページから抽出できます。マージのコンフリクトを避けるためには、trunk で行われたのと同じ順番でコミットをチェリーピックすることが重要です。これは、ラベルビューに表示される順番と同じではない可能性が高いので、マージされた日付を再確認し、必要に応じてコミット履歴を参照します。複数のコミットを、このようにひとつのコマンドにまとめることもできます:
git cherry-pick c82094d8389b1756f05d4079ba98e4ee25961502 && git cherry-pick 548e600f14924d7fcfdb5250f45f718d3759d022 && git cherry-pick b72b41e27f008540410c45023b655c8ee20b67ae
- チェリーピックの自動化が
- マージはコンフリクトする場合があります。もしコンフリクトが起きたら、それを解決しなければなりません。もしサポートが必要であれば、プルリクエストの作者にメッセージを送ってください。
- チェリーピックされたコミットが、リリースブランチに含まれていない別のコミットに依存しているためにコンフリクトが起こることがあります。これは意図されたものではないかもしれないため、プルリクエストの作者に連絡して再確認することをおすすめします。
- 手動でコンフリクトを解決した後、元のプルリクエストに戻り、
Backport to WP Beta/RCラベルを削除してください。 - GitHub で、作成したブランチから
wp/x.xブランチにプルリクエストを作成します。 - プルリクエストの継続的インテグレーションが成功したことを確認します。
- 解決すべきマージコンフリクトがある場合は、競合しているコミットの作成者に連絡し、それらが正しく解決されたことを再確認することをおすすめします。それ以外の場合、すべてのテストが CI で合格した場合は、プルリクエストをリリースブランチにマージしても問題ありません。
- マージ後、リリースブランチからパッケージ公開タスクを実行します:
- このページで、「Run workflow」ボタンをクリックし、リリースブランチを選択します。リリースタイプは
wpで、その下にリリースバージョンが追加されます。 - ワークフローが下のリストに表示されたら、クリックして承認します。
gutenberg-coreへのアクセス権を持っていない場合は、アクセス権を持っている人に承認を依頼してください。 - このワークフローは、リリースに対応する dist タグを持つ npm パッケージを公開します。これは、コアで正しいパッケージバージョンを選択するために使用できます。
- このページで、「Run workflow」ボタンをクリックし、リリースブランチを選択します。リリースタイプは
パッケージの更新とコアパッチ
- npm パッケージが公開されると、自動化スクリプトを使用して
wp-developリポジトリで更新できます:npm run sync-gutenberg-packages -- --dist-tag=wp-<VERSION>。新しくリリースされた@wordpressパッケージと同じ dist-tag を使用することを忘れないでください。たとえば、wp-6.2はメジャーバージョン6.2です。 - 次に、
wordpress-developフォルダーでnpm run postsync-gutenberg-packagesを実行します。新しい Gutenberg ブロックがコアに含まれ、必要なビルドが実行されます。 - 動的ブロックに新しいフロントエンドスクリプトが追加された場合は、webpack block config の参照に手動で追加する必要があります。
- sync タスクと postsync タスクの両方を実行した後、PHP ファイルや block.json ファイルに変更があったブロックについて正しいファイルが更新されたこと、および新規ブロックについてファイルが生成されたことを確認します。
- ローカルの WordPress 開発環境で、解決されるはずの問題が実際に解決されていることを確認します。
- コアのパッケージを更新するために Trac チケットを作成します。
wordpress-developに対してプルリクエストを提出し、継続的インテグレーションのテストがパスしたことを確認し、説明に Trac のチケット番号を追加します。これにより、プルリクエストがチケットにリンクされ、パッチが自動的に作成されます (以前の例)。- レビューを依頼します。ベータ版のフェーズでは、レビューは推奨されますが必須ではありません。RC プロセスでは、2人のコミッターによるダブルチェックが必要です。もしあなたがコミッターで、その変更に自信があるなら、承認者の一人として「dev-feedback」キーワードを追加してください。
- 承認されたら、パッチをコミットするか、コミッターでない場合はコミッターと調整してコミットされるようにしてください。
- WordPress リリースのブランチがすでに存在する場合は、trunk からリリースブランチへのコミットのバックポートが必要です。
最終更新日: