マイナーバージョンのリリース

Topics

WordPress のマイナーバージョンをリリースしたいですか ? リリースしたくないかもしれませんが、リリースせざるを得ないかもしれません。マイナーリリースは、新しくデプロイされるファイルを追加しないバグ修正や機能強化を目的としており、コンポーネントのメンテナーやコミッターからの提案やアドバイスを受け、リリースリードの裁量によって決定されます。以下に記載されているように、これらのリリースには多くのことが関係します。以前にリリースプロセスを実行したことがあり、何か不足しているものがある場合は追加してください。

リリースの前に

リリースを決定する前に、検討すべきことがいくつかあります [TODO: このセクションにさらに追加する]:

  • このリリースはセキュリティ修正のためですか ?
  • このリリースにはセキュリティ修正だけが含まれますか ?
  • このリリースにはどのようなメンテナンス修正が含まれますか ? それらのメンテナンス修正は trunk にコミットされましたか ?

マイナーリリースのフォーカス (セキュリティ、メンテナンス、またはその両方) に応じて、考慮すべきことがいくつかあります。

Top ↑

セキュリティ

セキュリティパッチは、時間に余裕をもって作成すること。trunk ブランチと安定版ブランチでは異なるパッチが必要になるかもしれません。現在、自動更新をサポートしている WordPress のすべてのバージョン (4.1以降) にパッチをバックポートするよう努めています。しかし、パッチのバックポートが常に可能であるとは限らず、そのため、これらのバージョンの WordPress は公式にはサポートされません。

セキュリティチームのハンドブックにあるプロセスに従って、パッチが後方互換、バイパス、実際のケースについて十分にテストされていることを確認してください。

すべてのパッチは十分にテストされ、リリース予定日の少なくとも5日前には WordPress セキュリティチームの承認を受ける必要があります。セキュリティの修正には trunk で仕上げる十分な時間がないため、早期にこのフィードバックを得ることは非常に重要です。

サードパーティから報告されたセキュリティ修正については、彼らがどのようにクレジットされたいかについての情報を入手してください。wordpress.org/news/ のアナウンス投稿では、サードパーティの要望に応じて、サードパーティの名前をクレジットします。

リリースの12時間前 (またはそれ以前) には、アップデート API の TTL を60分に下げる必要があります。これは、リリースまでに、すべての WordPress インストールが WordPress の新しいバージョンを1時間ごとにチェックすることを意味します。TTL を下げるには、versions.php 内の定数 WP_CORE_SHORT_API_TTL_VERSION をリリース予定のバージョン番号に更新します。このファイルは w.org サンドボックスへのアクセスを必要とするため、サンドボックスの1つが用意されている必要があります。

リリース当日、テストが失敗したり、セキュリティ修正が正常に動作しなくなったりしたら、punt してください。直前になって修正しようとしないでください。リリースのスケジュールを変更するか、リリースに修正を含めないでください。直前の修正は大きなバグにつながる可能性があります。

セキュリティ修正は準備できましたか ? よいでしょう。メンテナンスの修正がありますか ? あるなら、続けて読んでください。なければ、次のセクションはスキップしてください。

Top ↑

メンテナンス

セキュリティの修正とは異なり、メンテナンスの修正はいつでも trunk に追加できます。Trac のクエリーには、次のマイナーリリースを対象としたチケット専用のものがあります。メンテナンスリリースを考えているのであれば、念頭においているチケットに加えて、これらのチケットにも目を通すようにしてください。リリースがメンテナンスリリースであると判断したら、ブランチにパッチを追加し始めましょう。早ければ早いほどよいです。

理想的には、リリースの少なくとも48時間前にはすべてのパッチがリリースされ、リリース候補がビルドされます。これは正式なリリース候補でも、すべての修正を含むナイトリービルドでもかまいません。ベータ版やリリース候補版をビルドしたら、make/core に、リリースに含まれる修正点のリストとともに投稿してください。こうすることで、より多くの人に新しいビルドをテストしてもらうことができます。

Top ↑

両方

どのようなリリースを計画している場合でも、やるべきことが沢山あります。

  • 開発者ノートを必要とする重要な変更がないか確認します。これらはリリース前に公開され、マイナーリリース番号、関連するメジャーリリース番号、開発者ノートタグ (例:「4.9、4.9.2、dev notes」) がタグ付けされていることを確認してください。
  • 最新バージョンの Akismet が WordPress のビルドに含まれていることを確認します。現在では、Akismet チームに連絡して、アップデートに含めるプラグインのリリースが近いかどうかを確認する必要はありません。これは、ユーザーが新しいサイトを作成した直後にアップデートのプロンプトが表示されることを防ぐために重要なことです。これは自動化されています (関連する議論)。build.svn にコミットして Akismet external を最新バージョンに更新する例はこちらです (これは手作業による古い方法です)。
  • セキュリティチームのメンバーにプライベート・セキュリティ・ユニットテストスイートを実行してもらい、リグレッションが発生しないことを確認します。一部のサイト (wordpress.org など) では本番環境で trunk またはベータ/RC が稼働しているため、見つかった場合はその詳細について公の場で議論することは避けてください。代わりに、セキュリティ・チームに個人的に通知してください。
  • 数日前に、リリースが予定されていることをホストに通知するとよいでしょう。3日前が推奨されますが、リリースのスケジュールによっては不可能な場合もあります。セキュリティチームがホストへのメッセージについてお手伝いします。このメッセージは、(セキュリティリリースの場合) すべてのセキュリティパッチが準備できるまで出してはいけません。
  • リリースに 文字列の変更がある場合は、事前に Polyglots チームに知らせてください。
  • 最後のリリースタグとリリースブランチの間の src/ ディレクトリの差分をとり、新しいファイルが追加されていないことを確認します。これらのファイルは自動アップグレードを妨げることが多いためです。
  • WordPress.org のニュースブログへの投稿が必要です。一般的には、少なくとも1日前には始めるべきです (時間があればあるほどよいでしょう)。以前のリリースからフォーマットをコピーできます。リリースに貢献したすべての人の完全なリストを得るために、必ずログを grep してください。props のリストは、サンドボックスにアクセスできる人が wporg/bin/core/props-parser.php を実行することで最も効率的に集めることができます。
  • システムチーム (例: @barry、@abbe、@sysmonk) にリリースについて知らせておくことで、何か問題があった場合に備えて、誰かが対応できるように計画しておくことができます。リリースの時間を早く設定すればするほど、より早くこれを行うことができます。
  • リリースするバージョンごとに、リリース の Wiki テンプレートを使って、Codex ページを用意してください (手順はそのページに記載されています)。リリースがセキュリティに関するものである場合、これらのページは実際のリリース日までほとんど空白でもかまいませんが、WordPress 自体にリンクするため、存在する必要があります。

すべての作業が完了したら、いよいよリリース日を迎えます。

Top ↑

リリース日

リリース日はストレスになるかもしれません。リリース日を乗り切る最善の方法は、冷静さを保つことです。うまくいかないこともあるでしょう。大丈夫です、気を取り直してもう一度進んでみましょう。リリース日に行う必要があることのリストは次のとおりです:

  • 新しい貢献者をリストアップするために、関連するクレジットファイルを更新する必要があります。このファイルは meta リポジトリにあります。
  • セキュリティリリースを実行する場合、セキュリティパッチをすべての関連ブランチにコミットする必要があります。
  • セキュリティパッチがコミットされたら、リリースプロセスを #core チャンネルに移動してください。
    • (/here Slack コマンドを使用して) リリースパーティーへの参加を歓迎するアナウンスを行うことから始めます。
    • コミッターに対して、リリースが完了するまでコミットを控えるようリクエストを投稿します。例: @committers please refrain from committing during the release process。
  • バージョンアップは関連するすべてのブランチでコミットする必要があります。これがその例です。コアコミッターであれば誰でもこのステップを実行できます。最新のブランチでバージョンアップをコミットする際には、version.php と about.php の両方を更新してください。package.json ファイルは現在のブランチですでに更新されているはずですが、それ以前のブランチでは更新する必要があります (例)。
    • package.json には X.Y.Z への単純なバージョンアップが1つあります。
    • version.php には X.Y.Z-src へのバージョンアップが一つあります。接尾辞の -src は、develop.svn にコミットする際に常に含める必要があることに注意してください。
    • about.php の見出しである「Maintenance and Security Release(s)」に Z という数字を追加し、下部にある既存の文字列を使用して、リリースの変更点を説明する段落を追加する必要があります。これらの文字列はブランチによって異なりますので、必ず正しいバージョンのものを使用してください。他の場所から適切な段落をコピー & ペーストすることが一番簡単です。これがブランチの最初のマイナーリリースである場合、ナビゲ―ションタブの後に追加するラッパー div と前述の h3 もあります。単一または複数のセキュリティやバグの修正について、考えられる文字列の組み合わせをメモしておきます。違いについては、より完全な説明をチェックしてください。
    • これらの変更を事前に十分に準備し、レビューを依頼しましょう。そうすることで、リリースプロセスの停滞を避けることができます。バージョンアップとアバウトページは一緒にコミットでき、別々に行う必要はありません。
  • すべてのブランチで、リリースにはタグが必要です。多くの人は SVN からリリースを実行し、そのためにタグに依存しています。タグ付けは以下のコマンドで完了します (関連ブランチとリリースで必ず更新してください): svn cp https://develop.svn.wordpress.org/branches/5.7 https://develop.svn.wordpress.org/tags/5.7.2 -m "Tag 5.7.2" https://develop.svn.wordpress.org がチェックアウトするリポジトリのルートであることを二重三重にチェックした場合は、^ ショートカットを使用できます: svn cp ^/branches/5.7 ^/tags/5.7.2 -m "Tag 5.7.2".
  • リリースパッケージは、リリースされる各バージョンのタグをもとにミッションコントロールでビルドする必要があります。パッケージ化されたら、手動での更新テストを含め、十分にテストする必要があります。(どうやって行うのですか ? ドキュメントをチェックしてください)。
  • 自動更新は dotorg リポジトリにある versions.php ファイルで有効にする必要があります。(このファイルは dotorg サンドボックスへのアクセスを必要とするため、サンドボックスが用意されている必要があります)。自動更新を有効にするには、WP_CORE_LATEST_RELEASE 定数に新しいバージョン番号を設定し、自動更新を開始する時間を WP_CORE_AUTOUPDATE_RAMP_START に設定します。これは予想されるデプロイの数分後であるはずです。また、すべての新しいバージョンと一致するように wporg_get_version_equivalents() 配列を更新し、対応する古いバージョンを古いバージョンの配列に追加する必要があります。
    • 提供されるパーセンテージは、指定された時間の間に50%から100%まで上昇します。これは WP_CORE_AUTOUPDATE_RAMP_START 定数と WP_CORE_AUTOUPDATE_RAMP_PERIOD 定数によって制御されます。これらは以前の定数 WP_CORE_AUTOUPDATE_PERCENT と連携して動作し、いくつかのリリース中に手動で WP_CORE_AUTOUPDATE_PERCENT を低い値に変更する必要性をなくし、自動化します。
    • セキュリティリリースの場合は、wporg_get_secure_versions() を安全でない各ブランチ内のレガシーバージョンと一致させる必要があります。
    • デプロイ
  • すべてが期待通りに動作していることを確認してから、WP_CORE_AUTOUPDATE_RELEASE をバージョンアップしてデプロイします。
  • 自動アップデートの統計が正常であることを確認してください (成功率は99.9%以上で、残りの0.1%は安全に中断またはロールバックされます)。
  • リリースの言語パックは、translate/bin/update-all-core-packs.sh のバージョンを上げてビルドし、デプロイする必要があります。(このファイルは dotorg サンドボックスへのアクセスを必要とします)。
  • wordpress.org/news/ の投稿を公開する必要があります。
  • この時点でリリースパーティは完了し、管理タスクのみが残ります。
    • リリース中にテストに協力してくれた参加者に感謝します。
    • コミッターにコミットができるようになったことを伝えます: @committers feel free to commit as usual, thank you for your patience during the release
  • リリースしたことを make/polyglots に知らせます。ロケールによっては、自動ビルドに頼らず独自のビルドを行い、独自にパッケージ化する必要があります。これがその例です。
  • すべての HelpHub バージョンページを更新します:
  • Codex の CurrentVersion テンプレートを新しいバージョンに更新します。
  • Codex WordPress Versions ページに新しいバージョンを追加します。
  • REST API に変更があった場合は、dev hub の REST API changelog を更新してください。
  • Trac で、X.Y.Z+1 の新しいマイルストーンを作成し、古いマイルストーンを完了としてマークしてください。これは Trac の管理者が行う必要があります。
  • Trac で、X.Y.Z+1 リリース (バックポートを含む最新のブランチ) の新しいバージョンを作成してください。Released 日付フィールドから日付を削除してください。これも Trac の管理者が行う必要があります。
  • 最新の安定版ブランチのバージョンを X.Y.Z+1-alpha-$REVNUM-src にバージョンアップし、対応する package.json と readme を変更します。
  • 最新の安定版ブランチのナイトリーバージョンを再ビルドします。

Top ↑

スケジュール

上記の手順に従い、(世界中のすべての時間で) 理想的なスケジュールを立てると仮定すると、次のようなスケジュールを使用するとよいでしょう:

いつ ?何を ?
T-7:00:00すべての対象チケットをトリアージする。
T-5:00:00すべてのセキュリティパッチが、WordPress セキュリティチームによって作成、テスト、クリアされている。
T-4:00:00セキュリティパッチ以外のすべてのパッチを関連するブランチにコミットする。
T-4:00:00プライベート・セキュリティ・ユニットテストスイートを実行する。
T-3:00:00リリースが近付いていることをホストに知らせる。
T-1:00:00WordPress.org/news/ ブログ投稿を (下書きとして) 作成する。
T-0:12:00セキュリティ修正がある場合は version-check API の TTL を60分に下げてください (version.php の WP_CORE_SHORT_API_TTL_VERSION 定数)。
T-0:05:00セキュリティパッチをコミットし、ユニットテストとセキュリティテストを実行する。
T-0:00:31関連するすべてのブランチでバージョンアップを行う。
T-0:00:30ミッション・コントロールでリリース・パッケージをビルドする。パッケージをテストし、アップデートを手動でテストする。
T-0:00:00自動更新を有効にする (WP_CORE_LATEST_RELEASE 定数、version.php の wporg_get_versions() 関数と wporg_get_version_equivalents() 関数)。
T+0:00:01WordPress.org/news/ のブログ記事を投稿する。
T+0:00:15クレジットを更新する (リリースの前または後)。
T+0:01:00自動更新が (ほとんどの部分で) 完了しました。
T+0:01:00リリースにタグを付ける。多くの人が WordPress を SVN から実行しており、デプロイするためにタグ付けされたリリースが必要です。

Top ↑

追加のタスク

Top ↑

アバウトページの文字列を選択する

リリースを説明するアバウトページの段落には、文字列に関する5つのオプションがあります。

  • セキュリティの問題が1つあり、バグ修正がない場合: <strong>Version %s</strong> addressed one security issue.
  • 複数のセキュリティ問題があり、バグ修正がない場合: <strong>Version %s</strong> addressed some security issues.
  • 1つ以上のバグがある場合、_n() を <strong>Version %1$s</strong> addressed %2$s bug. と <strong>Version %1$s</strong> addressed %2$s bugs. という文字列と一緒に使用し、ロケールに適切な文字列が決定されるようにします。
  • セキュリティの問題が1つあり、バグが1つ以上修正されている場合、_n() を <strong>Version %1$s</strong> addressed a security issue and fixed %2$s bug. および <strong>Version %1$s</strong> addressed a security issue and fixed %2$s bugs. という文字列と一緒に使用し、ロケールに適切な文字列が決定されるようにします。
  • セキュリティの問題が1つ以上あり、バグが1つ以上修正されている場合、_n() を <strong>Version %1$s</strong> addressed some security issues and fixed %2$s bug. と <strong>Version %1$s</strong> addressed some security issues and fixed %2$s bugs. という文字列と一緒に使用し、ロケールに適切な文字列が決定されるようにします。

数字とともに文字列がどのように変化するかについては、他の最近のポイントリリースを参照してください。文字列をチェックし、コミットする前にレビューを受けてください。

Top ↑

パッケージビルドのテスト

パッケージのビルドをテストする方法はいくつかありますが、WP-CLI を使用することが早く効果的な方法です。ここでは、バージョン間のアップグレードをテストするために使用できるコマンドを紹介します。この例では、4.5.2と4.5.3の間をテストし、WordPress バージョン3.7以上がすでにインストールされていると仮定します。

  • $ wp core download --version=4.5.2 --force 開始したいバージョンを取得します。
  • $ wp core update-db 必要なデータベースを取得します。
  • $ wp core update https://wordpress.org/wordpress-4.5.3.zip テストするパッケージに更新します。
  • $ wp core update-db データベースのアップデートが実行されていることを確認します。

その後、テストサイトをチェックして、すべてが正常であることを確認してください。アップグレードのテストを楽しんでください !

原文 / 日本語訳

最終更新日: