ベータ版と RC 版のリリース

これらは、WordPress のベータ版をリリースする際に必要な手順です。将来の貢献者がより簡単に行えるように、この手順を進める中で不足している情報があれば、以下の手順に追加してください。

  • アナウンス記事を下書きする。
    • 以前の 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)。
  • ベータ1リリースの場合、#fse-outreach-experiment の FSE Outreach Experiment の参加者と調整し、「Help Test WordPress X.Y」の投稿を公開・宣伝することを強く推奨します (例: 6.1の投稿、6.1の Slack メッセージ)。
  • ベータリリースの場合、マイルストーンから機能強化や機能追加のリクエストチケットが取り除かれていることを確認してください (例: 6.1の Trac クエリー)。ある機能強化や機能要求がリリースにとって重要であり、マイルストーンに残す必要があるという合意がリリースチーム内にある場合、そのチケットタイプは「Task (blessed)」に変更されるべきです。また、Gutenberg からの機能強化/機能マージも同様にマイルストーンからクリアされるか、「Task (blessed)」に変更されることをエディターテックリードと確認してください。
  • RC リリースの場合、マイルストーンからすべてのチケットが削除されていることを確認するか、なぜチケットが残っているのかについてリリースチーム内で合意してください (例: 6.1の Trac クエリー)。また、Gutenberg からのすべてのマージもマイルストーンからクリアされていることをエディターテックリードと確認してください。
  • 開始する前に、すべてのユニットテストをローカルで実行します。
    • これらのテストを実行する前に、npm パッケージが最新の変更を反映するようにローカルで更新されていることを確認します
    • phpunit --stop-on-failure
    • phpunit --group ajax --stop-on-failure
    • phpunit -c tests/phpunit/multisite.xml --stop-on-failure
  • マイナーリリースでは、そのマイルストーンでクローズされたチケットがすべてリリースにマージされていることを確認してください (fixed-major がないチケットを探すことで絞り込めます)。マイナーリリースには、オプションでベータリリースを含めることができます。その判断はリリースリードの裁量に任されています。
  • 誰もコミットしようとしないように、#core でアナウンスします。
    • 例 (アーカイブ): @committers Please refrain from committing until we get 4.8-beta2 released.
  • リリースパーティに参加する人たちに、テストが終わるまでリリースパッケージへのリンクを共有しないよう注意を促してください。
    • 例 (アーカイブ): 注意: テストが完了し、WordPress.org でアナウンス記事が公開されるまで、パッケージへのリンクを公開しないでください。
  • リリースパーティに参加する人たちに、関係のないチャットは控えるよう注意すること。
    • 例: 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 チェックがパスしていることを確認します (つまり、すべて ✅ が表示されます)。
    • https://github.com/WordPress/wordpress-develop/actions?query=event%3Apush+branch%3Atrunk の最新コミットをチェックします。
  • マイナーリリースについては、リリースブランチをチェックしてください: svn switch '^/branches/4.7' を実行し、現在インストールされているものをアップデートするか、新たにインストールするよう人々に呼びかけます。
  • セキュリティチームのメンバーに、プライベート・セキュリティ・ユニットテストスイートを実行してもらって、リグレッションが発生しないことを確認してください。
    • 何か問題が見つかった場合は、その詳細について公の場で議論することは避けてください。一部のサイト (wordpress.org など) では、本番環境で trunk またはベータ/RC が実行されているためです。代わりに、セキュリティチームに非公開で通知してください。
  • バージョンを上げます。
    • trunk/src/wp-includes/version.php の $wp_version を更新します (例: $wp_version = ‘5.8-beta1-src’;)。
    • package.json の version がまだ更新されていなければ更新します。
    • もし $wp_version が 4.8.1-beta1 ならば、package.json の version は 4.8.1 だけでよいでしょう。
    • RC 版をリリースする場合、$wp_version は 4.8.1-RC1-src となります。
    • $wp_version を更新して適切なバージョン識別子を追加し、SVN のチェンジセット番号を削除します:
    • https://build.trac.wordpress.org/ にバージョンバンプが表示されていることを確認します。これは Mission Control 経由でリリースする人が確認する必要があります。
  • パッケージをビルドします。
    • リリースパッケージは Mission Control でビルドする必要があります。パッケージ化されたら、手動でアップデートをテストするなど、十分にテストする必要があります。(その方法は ? ドキュメントをチェックしてください)。
    • ビルド名を入力しましたか ?
    • ボタンをクリックしましたか ?
  • パッケージをテストします。
    • URL をシェアしてテストしてもらいます (例: https://wordpress.org/wordpress-4.9-beta2.zip)。
    • パッケージをテストするには、3つの方法があります:
      • WordPress Beta Tester プラグインをインストールし、有効化します
        • メジャー RC リリースの場合は、Bleeding edge チャンネルを選択し、次に Beta/RC Only ストリームを選択します。
        • マイナーな RC リリースの場合は、Point Release チャンネルと Nightlies ストリームを選択してください (Nightlies がビルドされるまでは、ベータテスターを使ってマイナーなベータ/RC パッケージをテストできません)。
      • WP-CLI を使ってテストします: wp core update https://wordpress.org/wordpress-4.9-beta2.zip
      • ベータ/RC バージョンを直接ダウンロードします (例: https://wordpress.org/wordpress-5.8-RC4.zip)
    • 注意: 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 ファイルを削除し、新規インストールをテストする
      • シングルサイトとマルチサイト/ネットワーク (サブディレクトリとサブドメインの両方) のインストールをテストする
  • もう一つのバージョンアップ。
    • コミット: WordPress 4.8ベータ2のバージョンアップ後。
  • 以前のコミットが 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-feedback and dev-reviewed Trac keywords on each ticket.
  • ベータ版のリリースプロセスでテストやその他の手伝いをしてくれた人全員に感謝し、賛辞を贈るメッセージを #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 プログラムの参加者にメールを送り、安定版リリースに入る前に新しい脆弱性を見つけてくださいと促すべきです。詳細は、セキュリティチームハンドブックを参照してください。
  • リリースサイクルの最初の RC の場合:
    • リリースサイクルの特定の部分をより明確にし、コミュニティを準備するために、リリース候補フェーズ (6.0の例) と上記のさまざまなプロトコルについて、Make Core でアナウンスされるべきです。

#props

原文 / 日本語訳

最終更新日: