これらは、WordPress のベータ版をリリースする際に必要な手順です。将来の貢献者がより簡単に行えるように、この手順を進める中で不足している情報があれば、以下の手順に追加してください。
- ベータ1リリースの場合、#fse-outreach-experiment の FSE Outreach Experiment の参加者と調整し、「Help Test WordPress X.Y」の投稿を公開・宣伝することを強く推奨します (例: 6.1の投稿、6.1の Slack メッセージ)。
- アナウンス記事を下書きする。
- 以前の wordpress.org/news/ の投稿をコピーし、そこから編集をはじめます (例: ベータ1、ベータ2、RC1、RC2)。
- 下書きを作成する際、サイドバーの「ステータスと公開」パネルにある「パブリックプレビューの有効化」オプションにチェックを入れ、プレビューの URL をコピーして他の人と共有し、公開前にレビューやフィードバックを提供できるようにしてください。
- リンク、チケット数、その他の要素が特定のベータリリース用に更新されていることを確認してください。ロケール間の互換性のために、Trac クエリーのリンクで URL の日付が
YYYY-MM-DDフォーマットであることを確認してください。 - リリースのリードから正確さのレビューを受け、マーケティングやドキュメントの担当者からコピー編集を受けます。これらの人々は、投稿の最後に @ で言及されるようにします。
- このベータ/RC リリースが元々計画されていなかった場合 (たとえば、RC の前に追加のベータをリリースしたり、最終リリースの前に追加の RC をリリースしたりした場合)、これらのアナウンス投稿は wordpress.org/news/ では公開されず、代わりに make.wordpress.org/core で公開されるという意味で、歴史的に「サイレント」であることに注意してください (例: 5.7 RC 3 や 6.2 Beta 5)。
- ベータリリースの場合、マイルストーンから機能強化や機能追加のリクエストチケットが取り除かれていることを確認してください (例: 6.1の Trac クエリー)。ある機能強化や機能要求がリリースにとって重要であり、マイルストーンに残す必要があるという合意がリリースチーム内にある場合、そのチケットタイプは「Task (blessed)」に変更されるべきです。また、Gutenberg からの機能強化/機能マージも同様にマイルストーンからクリアされるか、「Task (blessed)」に変更されることをエディターテックリードと確認してください。
- RC リリースの場合、マイルストーンからすべてのチケットが削除されていることを確認するか、なぜチケットが残っているのかについてリリースチーム内で合意してください (例: 6.1の Trac クエリー)。また、Gutenberg からのすべてのマージもマイルストーンからクリアされていることをエディターテックリードと確認してください。
- 開始前に、少なくとも1時間のコードフリーズを行うことをおすすめします。これは、リリースパーティー開始前に、懸念事項を洗い出す最後の機会となり、作業中の人々に短い休憩を与えるためです。
- 開始前に、すべてのユニットテストをローカルで実行します。これにより、ユニットテストなどの自動化されたアクションがリリースパーティー開始前に完了します。
- これらのテストを実行する前に、npm パッケージが最新の変更を反映するようにローカルで更新されていることを確認します
phpunit --stop-on-failurephpunit --group ajax --stop-on-failurephpunit -c tests/phpunit/multisite.xml --stop-on-failure
- マイナーリリースでは、そのマイルストーンでクローズされたチケットがすべてリリースにマージされていることを確認してください (
fixed-majorがないチケットを探すことで絞り込めます)。マイナーリリースには、オプションでベータリリースを含めることができます。その判断はリリースリードの裁量に任されています。 - 誰もコミットしようとしないように、#core でアナウンスします。
- 例 (アーカイブ): @committers Please refrain from committing until we get 4.8-beta2 released.
- リリースパーティに参加する人たちに、テストが終わるまでリリースパッケージへのリンクを共有しないよう注意を促してください。
- 例 (アーカイブ): :siren: Reminder: Please do not share links to the package publicly until the all-clear is given after testing and the announcement post is published on WordPress.org. :siren:
- リリースパーティに参加する人たちに、関係のないチャットは控えるよう注意すること。
- 例: Reminder: Please refrain from non-relevant chatting. This is an important process, and a lower signal-to-noise ratio isn’t helpful if something goes wrong.
- 最新の GitHub Action チェックがパスしていることを確認します (つまり、すべて ✅ が表示されます)。
- マイナーリリースについては、リリースブランチをチェックしてください:
svn switch '^/branches/4.7'を実行し、現在インストールされているものをアップデートするか、新たにインストールするよう人々に呼びかけます。 - セキュリティチームのメンバーに、プライベート・セキュリティ・ユニットテストスイートを実行してもらって、リグレッションが発生しないことを確認してください。
- 何か問題が見つかった場合は、その詳細について公の場で議論することは避けてください。一部のサイト (wordpress.org など) では、本番環境で
trunkまたはベータ/RC が実行されているためです。代わりに、セキュリティチームに非公開で通知してください。
- 何か問題が見つかった場合は、その詳細について公の場で議論することは避けてください。一部のサイト (wordpress.org など) では、本番環境で
- バージョンを上げます。
trunk/src/wp-includes/version.phpの$wp_versionを更新します- ベータ版の場合:
$wp_version = '5.8-beta1-src'; - リリース候補版の場合:
$wp_version = '5.8.1-RC1-src';
- ベータ版の場合:
- Update the
versioninpackage.jsonif it has not been updated yet. Theversioninpackage.jsonshould not contain-beta1-srcor-RC1-src. For example,5.8.1-RC1/5.8.1-RC1-srcshould be just5.8.1. Note: thepackage-lock.jsonfile must not be edited manually. Change the version specified inpackage.jsonand runnpm installto update the lock file. package.jsonのversionがまだ更新されていない場合は更新してください。package.jsonのversionには-beta1-srcや-RC1-srcを含めないでください。たとえば、5.8.1-RC1/5.8.1-RC1-srcの場合は5.8.1のみを指定してください。注意:package-lock.jsonファイルは手動で編集しないでください。package.jsonで指定されているバージョンを変更し、npm installを実行してロックファイルを更新してください。composer.jsonのversionがまだ更新されていない場合は更新してください。package.jsonと同様に、バージョンには beta または RC という接尾辞を含めないでください。- https://build.trac.wordpress.org/ にバージョンバンプが表示されていることを確認します。これは Mission Control 経由でリリースする人が確認する必要があります。
- パッケージをビルドします。
- リリースパッケージは Mission Control でビルドする必要があります。上記の手順でビルドが表示された後、Mission Control がロード・更新される必要があります。
- パッケージ化されたら、手動でアップデートをテストするなど、十分にテストする必要があります。(その方法は ? ドキュメントをチェックしてください)。
- ビルド名を入力しましたか ?
- ボタンをクリックしましたか ?
- パッケージをテストします。
- URL (例: https://wordpress.org/wordpress-4.9-beta2.zip) と、テストすべき具体的な項目をハイライトしたテスト募集の投稿 (6.8 の例) を共有して、テストを依頼してください。パッケージのテストに協力する方法は3つあります:
- WordPress Beta Tester プラグインをインストールし、有効化します
- メジャー RC リリースの場合は、
Bleeding edgeチャンネルを選択し、次にBeta/RC Onlyストリームを選択します。マイナーな RC リリースの場合は、Point Release チャンネルと Nightlies ストリームを選択してください (Nightlies がビルドされるまでは、ベータテスターを使ってマイナーなベータ/RC パッケージをテストできません)。
- メジャー RC リリースの場合は、
- WP-CLI を使ってテストします:
wp core update https://wordpress.org/wordpress-4.9-beta2.zip - ベータ/RC バージョンを直接ダウンロードします (例: https://wordpress.org/wordpress-5.8-RC4.zip)
- WordPress Beta Tester プラグインをインストールし、有効化します
- 注意: WP-CLI 経由でアップデートを行った際にファイルが削除されたと報告された場合は、そのファイルが
$_old_files変数に存在することを確認してください。 - 注意: WP-CLI を使ってパッケージをテストしている人は、チェックサムに関する警告を受けるかもしれません。これはチェックサムがナイトリーバージョンでは利用できないためです。
- 理想的なテストの実施:
- 4.0.*リリースシリーズの最新版からテストする (例: 4.0.35から6.1ベータ1)
- 4.9.*リリースシリーズの最新版からテストする (例: 4.9.21から6.1ベータ1)
- 現在のメジャーリリースシリーズの最新版からテストする (例: 5.7.2から5.8ベータ2)
- 最新のベータ/RC リリースからテストする (例: ベータ2からベータ3、ベータ3から RC1、RC1から RC2)
- 新規インストールをテストする
wp-config.phpファイルを削除し、新規インストールをテストする- シングルサイトとマルチサイト/ネットワーク (サブディレクトリとサブドメインの両方) のインストールをテストする
- URL (例: https://wordpress.org/wordpress-4.9-beta2.zip) と、テストすべき具体的な項目をハイライトしたテスト募集の投稿 (6.8 の例) を共有して、テストを依頼してください。パッケージのテストに協力する方法は3つあります:
- もう一つのバージョンアップ。
- 以前のコミットが https://build.trac.wordpress.org/ に表示された後、Mission Control でナイトリーパッケージをリビルドする必要があります。
- アナウンス投稿を公開します (ベータ1リリースで投稿が作成された場合は、それに続く「Help Test WordPress X.Y」投稿も)。
- Matt がこれを行うことができますし、wordpress.org/news/ の管理者または編集者のアクセス権を持っている人なら誰でも行うことができます。
- 投稿内容を #polyglots チャンネルで共有し、翻訳版の作成に役立ててください (例: 6.1ベータ1の Slack メッセージで
code editorの内容を共有しています)。
- #core で、リリースが利用可能であることをアナウンスします。
- 例: /here WordPress 5.8 Beta 1 is now available. Please help test! There’s a lot to test this release.
- 注意事項として、5.8で追加された機能、テストの変更、ドキュメントの更新に関するチケットのみが、このリリースのベータ版で考慮されます。
- コミッターに、#core の SVN コミットがオープンしたことを知らせます。
- 例: @committers Feel free to resume committing.
- RC リリースの場合、コミットする前に
dev-feedbackとdev-reviewedのワークフローが必要であり、各コミットは二重チェックが必要であることに注意してください。- 例: @committers Feel free to resume committing. Reminder that we are now in the RC period so all commits will require double-signoff using the
dev-feedbackanddev-reviewedTrac keywords on each ticket.
- 例: @committers Feel free to resume committing. Reminder that we are now in the RC period so all commits will require double-signoff using the
- ベータ版のリリースプロセスでテストやその他の手伝いをしてくれた人全員に感謝し、賛辞を贈るメッセージを #props チャンネルに書き込みます。
- 例: Props to @mention, @mention2, …, @mentionN for helping test today’s 5.8 Beta 1 release!
- ベータ/RC リリースの場合は、リリース投稿、Slack アーカイブ、Zip ダウンロードへのリンクなど、リリースの詳細を含むサイクルの Make/Core ページを更新します。例: https://make.wordpress.org/core/6-4/。
- リリースサイクルの最初のベータ版の場合:
- 次のリリースバージョンの新しいマイルストーンをコア Trac に追加します。たとえば、WordPress
5.0をリリースするときに、5.1のマイルストーンを追加します。これを行うには、Trac の管理者権限を持つ人に依頼する必要があるかもしれません。 - セキュリティチームのメンバーは、HackerOne プログラムの参加者にメールを送り、安定版リリースに入る前に新しい脆弱性を見つけてくださいと促すべきです。詳細は、セキュリティチームハンドブックを参照してください。
- 次のリリースバージョンの新しいマイルストーンをコア Trac に追加します。たとえば、WordPress
- リリースサイクルの最初の RC の場合:
- リリースサイクルの特定の部分をより明確にし、コミュニティを準備するために、リリース候補フェーズ (6.0の例) と上記のさまざまなプロトコルについて、Make Core でアナウンスされるべきです。
