メジャーバージョンのリリース
Topics
古い情報や不明な点があるかもしれません。ご質問がある場合は、先行リリースリードまでご連絡ください。
おめでとうございます ! あなたは WordPress のリリースリードです ! これからの数ヵ月は、興奮と挫折、楽しさが渦巻く人生になるでしょう。WordPress のリリースをリードすることは簡単ではありませんが、とにかくすばらしい時間を過ごすことになるでしょう。
あなたの前にも沢山の人がいて、あなたの後にも沢山の人がいるでしょう。このページがあなたをゴールまで導いてくれるかもしれませんが、リリースリードはそれぞれ、リリースに独自のタッチをもたらします。迷ったときは、以前のリリースリードに相談し、指示を仰いでください。
はじめに
マイナーバージョンのリリースのハンドブックページは一読する価値があります。そのポイントの多くはメジャーバージョンのリリースにも当てはまるからです。リリース日が近付くにつれ、特にそう言えるでしょう。
あるリリースのリードに任命されたら、すぐに考えるべきこと、やるべきことをいくつか挙げてみます:
- リード、コミッター、コンポーネントメンテナーと話す。 初日には、リリースに何が含まれるのか見当もつかないかもしれません。さまざまな WordPress のリード、コミッター、コンポーネントメンテナーと時間をかけて、彼らが何を考えているのかを確認しましょう。このような話し合いは、リリースのスケジュールにもよりますが、数日、数週間、あるいは数ヵ月に渡って行われることもあります。
- スケジュールを設定する。 メジャーリリースの良いサイクルは4ヵ月ごとです。多くの場合、4月、8月、12月です。とはいえ、明確に決まっているわけではありません。スケジュールを設定する最良の方法のひとつは、リリース日を決め、その日から逆算することです。いくつかのヒントについては、以下のスケジューリングセクションをチェックしてください !
- リリースのサブリードを選ぶ。 リリースのサブリードを立てる必要はありませんが、立てることを強くおすすめします。いくつかのリリースのリードは2人以上のサブリードを持っていますが、それはまったく問題ありません ! ここでのコツは、あなたの才能を補強し、サイクル全体を通してアシストしてくれるサブリードを選ぶことです。ミーティングノートを書いたり、ミーティングを運営したりするのが苦手ですか ? そのようなことができるサブリードを選びましょう ! トリアージが苦手ですか ? 手伝ってくれるコミュニティメンバーがいるはずです。誰がサブリードになることに興味があるかわからない場合は、make/core にボランティア募集の投稿をしてください。(投稿には必ずタグをつけてください !)
- アイデアを募集する。 WordPress はボランティアによる大きなコミュニティによって構築されていますが、そのうち一部のみがコミッターやコンポーネントメンテナーです。リリースサイクルの早い段階で、make/core にリリースのアイデアを募集する投稿をしてください。その投稿から、個別のチケットや大きな機能のアイデアが得られます。それらをすべて整理するのは時間がかかりますが、リリースのために調査すべきことのすばらしいリストを得ることができます。
スケジュールについて
WordPress プロジェクトがグローバルになるにつれ、完璧なリリース日を見つけることが難しくなっています。ここでは、可能性の高いスケジュールを決定する際に注意すべきベストプラクティスをいくつか紹介します:
- リリース日自体についてはしっかりと決める。ただし、必要に応じてベータ版を追加したり、RC 版の日付を調整したりできるように準備しておくこと。
- 主要な祝日 (宗教上の祝日、銀行休業日、国民の祝日などを含む) をチェックする。
- コミュニティが参加する大きなイベント (WCUS、WCEU など) をチェックする。
役割と責任について
リリースの間にはいくつもの役割と責任があります。実際には、そのサイクルのリリースコーディネーターがいない場合、リリースリードとそのサブリードがリリースサイクル全体のプロジェクトマネージャー (およびテクニカルプロジェクトマネージャー) として活動します。そうでない場合は、リリースコーディネーターが、結束力のあるリリースチームによってさまざまな部分が適切にカバーされるようにします。
重要な注意事項: このハンドブックのページに記載されているタスクの多くは、「ミッションコントロール」または MC として行動する人々によって行われます。これらは、プロジェクトのためのより大きなメタタスクを実行する、特定の能力を持った人々のための非常に特別なセットです。もしやり方がわからなかったり、アクセスできなかったりした場合は、そのような人たちが処理するタスクである可能性が高いでしょう。
リリースリードとサブリードの責任を考える前に、有効なリリースリードの資質をいくつか理解しておくことが重要です:
- WordPress のしくみ (ソフトウェアとコミュニティの両方) を理解していること。 WordPress というソフトウェアは巨大なものです。一人の貢献者がコードベース全体を理解しているわけではありません。しかし、リリースリードとサブリードは、WordPress がどのように動作し、どのようにコアコミュニティが機能するかをよく理解している必要があります。さまざまなチケットについて誰に尋ねるべきかを知ることは、リリースをリードするための重要なスキルです !
- オープンソースがどのように機能するかについての知識。 オープンソースプロジェクトは、ほとんどのソフトウェアプロジェクトとはかなり異なっています。リリースリードやサブリードになるためには、オープンソースでグローバルな分散型プロジェクトの一員として働く能力があることが期待されます。
- コミュニティとの良好なコミュニケーション能力。 コミュニケーションは WordPress コミュニティのあらゆる部分で非常に重要であるため、良好なコミュニケーションが評価され、期待されます。中心的なコミュニティは、多くの貢献者が第二言語として英語を話しているにもかかわらず、このサイトや Slack では英語でコミュニケーションをとっています。このグローバルコミュニティにはさまざまなバックグラウンドがあるため、リリースリードやサブリードは公式・非公式チャンネルでコミュニケーションをとる際には注意が必要です。こちらもご覧ください: 投稿とコメントのガイドライン。
またリリースサイクルの中で、リリースリードとサブリードが持つ責任もいくつかあります:
- 議題の投稿、毎週の開発者チャットの運営、チャットの要約の投稿。 リリースサイクル全体を通して、情報は WordPress 開発者コミュニティ全体に提供されるべきです。すべてのコミュニティメンバーが毎週の開発者チャットに参加できるわけではないので、議題と要約を投稿する必要があります。
- チケットのトリアージとチケットレポートのモニタリング。 リリースには多くの重要な要素があります。リリースリードとサブリードは、新しく提出される trunk チケットを注意深く見守り、関連するチケットレポートを監視する必要があります。これには、(特に未所有のコンポーネントの) 新しいチケットレポートをトリアージして、ブロックする問題がないかチェックすることも含まれます。
- リリースを予定通りに進める。 期限を守ること。WordPress のリリースは、スケジュール通りに進むように努力すべきであり、リリースリードとサブリードがこのスケジュールに責任を持ちます (上記の「スケジュールについて」を参照してください)。リリースのスケジュールを維持するには多くの側面があり、その多くはここで責任として挙げられています。
- バグスクラブの開催。 バグスクラブを毎週開催することは、あらゆる種類の貢献者からの貢献を促す有用な活動です。この活動は、リリースリード、サブリード、その他の貢献者によってうまく運営できます。コンポーネントメンテナーもバグスクラブを行うことができます。
- 機能に関するアイデアを検討し、対応する。 WordPress の貢献者やユーザーは、リリースサイクル中、特にウィッシュリストの投稿に機能のアイデアを投稿します。各機能を開発することはリリースリード (またはそのサブリード) の責任ではありませんが、各機能のアイデアをレビューし、リリースに含める価値があるかどうかを確認する必要があります。これらのアイデアの多くは、機能に関するプロジェクトから出てくるものですが、中には注意が必要なチケットもあるでしょう。
- 助けてくれる貢献者を見つける。 すべての技術的な決定、あるいはその大部分を行うことは、リリースリードの責任ではありません。リリースリードは、いつどのように貢献者を探し出し、支援を求めるべきかを知っておくべきです。コアチームは大規模で、リソースの状況もさまざまであるため、リリースリードはさまざまなチケットに対してフィードバックやサポートを提供するために、どの貢献者が最適であるかをよく理解している必要があります。
- 貢献者と定期的にチャットする。 定期的に貢献者と連絡を取り合うことは、WordPress のリリースが安定し、公開の準備が整っていることを保証するために役立ちます。定期的に貢献者とチャットすることで、リリースリードは貢献者の稼働状況やブロックの可能性のある問題などを把握できます。
- マーケティング活動の調整。 管理するべきマーケティング活動がいくつかあり、リリースリードやサブリードはそれらを認識している必要があります。WordPress コアのアバウトページ、/news/ の投稿、ビデオはすべてこの取り組みの一部です (これらの具体的な取り組みについては後述します)。4.7で学んだように、動画を同時に自動再生するように設定することは避けるべきです。これらの活動は、マーケティングチームと関連するコンポーネントのメンテナーと連携して行うべきであることに注意してください。リリースコミュニケーションに関する詳細なハンドブックについては、このリリースサイクルのマーケティングとコミュニケーションガイドを参照してください。
- リリースや機能に対するあらゆる変更を伝える。 リリースが進むにつれて、大きな決断が必要になり、リリースチームによって適切に伝えられなければならないときがあります。そのためには、時にはプロジェクトのリーダーを巻き込みながら、一緒になって進むべき道を見つけることと、変更点を適切に伝えるために作業することの両方が必要です。あなたが所属するリリースチームが同じような状況に陥ったときのために、2つの例を挙げます。WordPress 5.9のリリーススケジュール変更のアナウンスと WordPress 6.0におけるウェブフォント API の変更点です。
期待されること
フォーカスリードは、タスクを実行するために少なくとも週に5～6時間は確保する必要がありますが、ベータ、リリース候補、正式リリースなどのマイルストーンが近付くにつれ、より多くの時間が必要になります。これらのマイルストーンの日には、1日に4～6時間を WordPress に費やす必要があるかもしれません。
出身地の制限はありません。私たちは24時間365日休みのないグローバルコミュニティですので、必要であればあなたの都合に合わせてスクラブのスケジュールを組み、他のタイムゾーンをカバーするサブリードを見つけられるかもしれません。
役に立つヒント
- コミュニケーションのために slack チャンネルを公開し、ベータ1の直前から毎週アップデートを行う。 これによって、将来の貢献者のためにリリースチームがオープンに活動できるようになり、また人々がフォローできます。#meta チームはこれを促進する手助けができます。
- リリースチームとリリースパーティ中には冗長性を確保する。 プロジェクトの規模に伴い、重要な役割に複数の人を配置し、リリースパーティ中にタスクを達成できる人が複数いるようにすることは、とても大切です。たとえば、複数の MC がいることで、事前に予定されていた MC が遅刻などにより参加できなくなった場合に、誰かが確実に対応できます。
- 前回のリリースで人々が何をしたかを調べる。 これはオープンソースのプロジェクトですので、あなたがすべきことの多くは、先人たちから学ぶことができます。Slack でリリースパーティについて調べたり、前のリリースリードに質問したり、Make で前の決定がどのように行われたかを調べたりしてください。
- サイクルの各パートには、それぞれ異なる制限とフォーカスがあることを認識する。 リリースサイクルが進むにつれてフォーカスは移り変わるので、それに合わせてシフトすることが重要です。たとえば、RC では コアコミットに対し二重チェックが必要ですので、その変数を念頭に置いて重要な作業を計画することが大切です。
- リリースパーティのスクリプトを作成し、リリース日のかなり前に調整する。 リリースパーティのスクリプトを作成したり、特定のステップを確実にこなせるよう関係者に確認したりなど、前もって十分に調整しておくことは当然です。必要かつ既知のストレス要因に対処しておくことで、予期せぬストレス要因が出てきたときに対応できます。
- 特に懸念事項がある場合は、早めに頻繁に共有すること。 自分にとっては当たり前のことでも、それを表現しなければ、グループ内では簡単に見過ごされてしまいます。
マージウィンドウの前に
- 機能に関するプロジェクトは、リリースサイクルの最初に統合の検討を準備するべきです。
- 統合の提案はこの時期に作成し、レビューされるべきです。
- 新しいバンドルテーマがこのリリースに含まれるかどうかを確認してください。
マージウィンドウ
- (もしあれば) どの機能プロジェクトを統合するかを決めます。
- リリースビデオが必要なら、その作業を開始します。
ベータ1の前に
- 開発者ノートを編集して公開を開始する。make/core で #dev-notes を使って、リリースの重要な変更点や開発者向けの主要な更新を開発者に知らせる記事の編集と公開を開始します。
- アバウトページ。リリースの注目すべき機能をまとめ始め、イラストを提供できるデザイナーを特定します。文章は RC1までに完成させ、画像は RC2まで更新できるようにします。マーケティングコミュニケーションハンドブックと同様に、アバウトページのプロセスに関する詳細情報もあります。
- HelpHub バージョンページ。デザイナー、開発者、ユーザーのために、注目すべきアップデートをまとめ始めます。5.2 バージョンページを例として使用できますし、ドキュメントチームに助けを求めることもできます。
- ブラウザーサポートページにリストアップされているブラウザーのどれかが、コアでそれらをサポートするために必要なパーセンテージを下回ったかどうかを確認し、更新が必要なものがあれば、以下の最終的なリリースの前における最終チェックと更新の1つになるので、そのための計画を立てます。
ベータ1
ベータ版リリースのプロセスは、別のハンドブックのページで詳しく説明されています。
リリース候補の前に
- リリースのマイルストーン時点で、オープンチケットが残っていてはなりません。
- フィールドガイドの公開プロセスは、別のハンドブックページにドキュメント化されています。
- (wp.org のリポジトリにある) すべてのプラグイン作者に、リリースとの互換性をテストするように知らせるメールを送るべきです。そのメールはフィールドガイドにリンクされるべきです。プラグインチームに連絡して調整するか、プラグインレビューチームが作るサイトでリリースメールの下書きを公開します (5.3のサンプルはこちら)。
- Classic Editor プラグインがまだうまく動作するかテストしてください。
- Akismet チームにリリースのスケジュールを伝え、最終リリースの前に保留中のプラグインのアップデートがリリースされるようにします。
- Akismet は WordPress のコミットごとに自動的に更新がチェックされ、必要であれば更新されます。
- プラグインは trunk、現在の安定版ブランチ、(trunk と異なる場合は) 現在の開発版ブランチで更新されます。
- ホスティングコミュニティには、メジャーバージョンの更新リリース日を通知する必要があります。リマインダーとして、#hosting Slack チャンネルにメッセージを投稿してください。
- 翻訳文字列のフリーズについて、Polyglots P2 でアナウンスしてください (5.9の例)。
- コミッターには、RC1がリリースされるときにリリース候補コミットポリシーが適用されること、特に RC フェーズでは、すべてのコミットがコミッターから二重チェックを得なければならないことを積極的に知らせるべきです。これは RC1がリリースされた後に始まるので、リマインダーでは、RC フェーズが近付いているが、まだ始まっていないことをみんなに知らせてください。
- プライベートセキュリティのユニットテスト・スイートを実行してください。
リリース候補
リリース候補バージョンは、メジャーバージョンがリリースされる前のリリースサイクルの最終フェーズとしてリリースされます。リリース候補版は、trunk にあるものがメジャーリリースに十分であるとリリースチームが自信を持っていることを意味し、コミュニティによって徹底的にテストされるべきです。
- 翻訳文字列のハードフリーズがリリース候補のフェーズで有効になります。これは、アプリケーションの文字列が、アバウトページのテキストを含めて、もはや変更できないことを意味します。
- 報告されたバグが修正されるにつれて、複数のリリース候補版 (たとえば RC1、RC2) がリリースされるべきです。
- リリース候補フェーズでの src/ に対するすべての変更は、2人のコミッターによってレビューされなければならないことをコミッターに警告してください。あなたのパッチをレビューする2人目のコミッターを選ぶときは、そのパッチを意味のあるレビューを受けられるように、コードベースのその領域で豊富な経験を持つベテランのコミッターを探しましょう。コミッターはいつでも tests/ にコミットできます。
- RC リリースのプロセスについては、別のハンドブックのページに詳しく書かれています。
- 最初のリリース候補に続いてリリース用のブランチを作成し、次のリリースに向けて trunk の初期作業を開始できるようにします。
- リリースサイクルの特定の部分をより明確にし、コミュニティを準備するために、リリース候補のフェーズ (6.0の例) と上記のさまざまなプロトコルについて Make Core でアナウンスする必要があります。
- この時点で、2つの Make Core 投稿を公開して、興味があり、(1) このメジャーリリースサイクルに続くマイナーリリースチームに参加できる人、および (2) 次のメジャーリリースチームに参加できる人たちの候補を集め始める必要があります。
translate.WordPress.org
Polyglots チームに、WordPress の次のバージョンの翻訳に協力してもらいましょう。以下のリストでは、リリース例を A.B. としています。
- メインの WordPress プロジェクトに A.B.x サブプロジェクトを作成します。
- 開発プロジェクトから翻訳セットをコピーします。
- 各開発サブプロジェクトに同じことを行います。
- /home/rosetta/public_html/wp-content/mu-plugins/rosetta/rosetta.php を更新して、GlotPress プロジェクトから WordPress ブランチへのマッピングと、Rosetta のプロジェクト名を追加します。
- A.B 言語パックのための A.B.x サブプロジェクトを使用するために、/home/wporg/public_html/translate/bin/update-all-core-packs.sh を更新します。
- Gutenberg プラグインの既存の翻訳を WordPress プロジェクトに移行します。
- Polyglots チームに文字列を通知します。
リリース前のブランチ
この時点で、マイルストーンがほぼ明確になれば、リリース用のブランチを作成し、トランクの初期作業を開始できます。ブランチを作成する際には、以下のファイルのバージョン番号を更新する必要があります:
src/wp-includes/version.php- 両方の NPM ファイル:
package.jsonとpackage-lock.json - trunk では、
SECURITY.mdファイルを更新して、新しく作成したブランチをセキュリティアップデートを受けているバージョンのリストに含めます
リリース前にブランチを行う場合、ブランチが行われた後に設定しなければならない重要なことが2つあります。理想的には、これらは trunk での開発作業が始まる前に行うべきです。
- API: /home/wporg/public_html/.config/versions.php の
WP_CORE_DEV_BRANCHをブランチ、たとえば4.9に設定します。これはコアの更新チェックで、ベータテスタープラグインのユーザーを (スーパーアルファ5.0にプッシュする代わりに) ブランチの開発パスに保持するために使用されます。 - 翻訳: 「WordPress 開発」プロジェクトが、trunk ではなくブランチから文字列 (“originals”) をインポートすべきであることを GlotPress に認識させるために、/home/wporg/public_html/translate/bin/update-originals-wp.sh の
DEV_BRANCHを更新します。これは、trunk での文字列の変更が生成される翻訳ファイルに影響することを防ぐために必要です。これはまた、翻訳作業が WordPress の最新の安定版で継続される間、数週間のリリース後に設定されることが多く、trunk では文字列の変更について何度も繰り返されることがあります。 - 翻訳: ベータ/RC パッケージ用のブランチを使うように /home/wporg/public_html/translate/bin/update-all-core-packs.sh を更新します。
- 翻訳:
wp/devプロジェクト用のブランチを使用するように /home/rosetta/public_html/wp-content/mu-plugins/rosetta/rosetta.php を更新します。
ブランチが実行された後、Test Old Branches GitHub Actions ワークフローを更新する必要があります。例として、5.8がブランチされた後にワークフローファイルを更新する PR を示します。
最終的なリリースの前に
これはリリース前のチェックリストです。スキップしないでください。このシートを複製して、調整に役立てることをおすすめします。また、リリースサイクルのこの部分に関係するより広い貢献者たちとともに、リリースチームの間でタスクを割り当て始めることをおすすめします。
- リリースのプロセスをまとめた投稿を、手伝いたい、あるいはフォローしたい人のために公開します (5.1の例)。
- リリースのジャズミュージシャンの名前を入手する (Matt か現在のプロジェクトディレクターに連絡を取ります)。
- クレジットページのために、注目すべき貢献者のリストを集めてください。これらのユーザーを管理するために、このスプレッドシートのテンプレート (5.4のサンプルデータです) を利用します。すべての注目すべき貢献者が Gravatar で写真を持っていることを確認してください。
- これには、Trac や GitHub からの props、そして手動で追加するコード以外の props も含まれるはずです。
- セクションがあります: すべてのリード、注目すべき貢献者 (コア開発者を含む)、すべての貢献者。リードと注目すべき貢献者は手動で編集されます。各フォーカスリードにリストを確認してもらいましょう。
- リリースのデザインリードは、コード props で見逃しているデザイナーがいないか確認してください。
- クレジット API を更新する必要があります。
- 最初の注目すべき貢献者セクション (開発者に限らないが、
core-developersという名前) にいる人全員に Core Team バッジをつけるべきです。
- 最初の注目すべき貢献者セクション (開発者に限らないが、
- about.php、freedoms.php、credits.php でタグラインが同期していることを確認してください。
- アバウトページの画像が CDN の URL を使っていることと、フィラー画像が最終バージョンに適切に置き換えられていることを確認してください。
- プライベートなセキュリティ・ユニットテストスイートを実行します。
- アナウンス投稿は下書きのままであるべきです。公開しないでください。
- これはアバウトページのコピーにもとづきますが、最後にビデオ (該当する場合) と props も含まれます。
- リリース投稿に props のリストを表示するには、次のショートコードを使用してください:
［wpcredits X.Y］。X.Y はリリースのバージョンです。これはクレジット API からデータを取得するので、リリース投稿のために props のリストを別に生成する必要はありません。 - コア props の後に、サポートボランティアと翻訳者への感謝の言葉を投稿に含めるようにしてください (5.6のような、以前のメジャーリリースのアナウンスの例を参照してください)。
- 投稿を「release」および「development」としてではなく、「release」のみに分類してください。
- ハッシュタグ #WordPress を含むツイートを更新します。
- 投稿を共有する際にリンクのプレビューに使用されるアイキャッチ画像を設定します。Twitter や Facebook などのプレビューで、画像の大部分が切り取られないようにします。必要であれば、Facebook では https://developers.facebook.com/tools/debug/、Twitter では https://cards-dev.twitter.com/validator を使ってキャッシュをクリアできます。
- 抜粋文を調整します。
- プレビュー URL に
&embed=trueを追加して、埋め込みがうまくいくようにします。
- プレビュー URL に
- いずれかのブラウザーのサポートを終了した場合は、ブラウザーサポートページを更新します。
ドライラン
リリースが予定されている24時間前にドライランを実行し、以下のステップを進めてください:
- trunk に対して報告されたバグをトリアージします。report 40の先頭で簡単に見つけることができます。
src/wp-admin/includes/update-core.phpを更新します。- 古いファイルをチェックし、それらが
$_old_filesにあるかどうかを確認します:svn diff --summarize [https://core.svn.wordpress.org/tags/4.4](https://core.svn.wordpress.org/tags/4.4) [https://core.svn.wordpress.org/trunk](https://core.svn.wordpress.org/trunk) | grep '^D'- 現在のメジャーがすでに
trunkからブランチされている場合は、svn diff --summarize [https://core.svn.wordpress.org/tags/6.1.1](https://core.svn.wordpress.org/tags/4.4) [https://core.svn.wordpress.org/branches/6.2](https://core.svn.wordpress.org/trunk) | grep '^D'を使ってください。 - 注意: Requests ライブラリから削除されたファイルは
$_old_filesには記録されません。代わりに$_old_requests_filesグローバルに追加する必要があります。
$_old_files名前のあるファイルが追加されていないかチェックします。追加されたファイルが$_old_filesにある場合は、追加されたバージョンと一緒にコメントアウトします。履歴のために、その行は削除しないでください。svn diff --summarize [https://core.svn.wordpress.org/tags/4.4](https://core.svn.wordpress.org/tags/4.4) [https://core.svn.wordpress.org/trunk](https://core.svn.wordpress.org/trunk) | grep '^A'- 現在のメジャーがすでに
trunkからブランチされている場合は、svn diff --summarize [https://core.svn.wordpress.org/tags/6.1.1](https://core.svn.wordpress.org/tags/4.4) [https://core.svn.wordpress.org/branches/6.2](https://core.svn.wordpress.org/trunk) | grep '^A'を使ってください。
$_new_bundled_filesが最新かどうかをチェックします。これは新しいデフォルトテーマごとに更新する必要があります。- 注意: デフォルトテーマから削除されたファイルは
$_old_filesにリストされるべきではありません。これらはコアのアップデートとは別に更新されるので、含める必要はありません。
- 古いファイルをチェックし、それらが
npm run grunt prereleaseを実行して、すべてのテストがパスし、CSS と JS ファイルが標準に準拠していることを確認する。(これには時間がかかります)
全員に通知する
- リリースが近付いていることをホストに通知します。
- 文字列の変更を polyglots チームに通知します。
- システムチームに通知して、リリース中に誰かが対応できるようにします。どのようにするのがベストかわからない場合は、リリースチームにこのチームに誰がいるのかを尋ねてください。
リリース日
リリース日に間に合いました !
コア
- report 40の先頭がトリアージされおり、クリアであることを確認します。
- コミッターに、リリースについて通知し、コミットを一時停止するよう警告します:
- 例: @committers 5.8がリリースされるまでコミットを控えてください。
- 該当する場合、
about.phpに最終コミットをします。たとえば、リリースビデオを入れたり、最終イラストを更新したりします。 package.jsonが更新されていることを確認してください。src/wp-admin/includes/update-core.phpを確認します。- 新しいデフォルトテーマがある場合は、以下を確認します:
src/wp-includes/default-constants.phpのWP_DEFAULT_THEMEを確認します。src/wp-includes/class-wp-theme.phpにあるWP_Theme::$default_themesを確認します。- 非常に重要:
/home/wporg/public_html/.config/versions.phpの中のWP_CORE_NEW_BUNDLED_VERSION
- ユニットテストを実行します。
npm run grunt prereleaseを実行します。これでユニットテストも実行されます。GitHub Actions の結果を確認します (例: https://github.com/WordPress/wordpress-develop/actions?query=branch%3A5.8)。src/wp-includes/version.phpのバージョンを更新し、RC 識別子とチェンジセットを削除します – 例:5.3-src。- リリースにタグを付けます。ブランチから:
svn copy https://develop.svn.wordpress.org/branches/4.7 https://develop.svn.wordpress.org/tags/4.7 -m "Tag 4.7"
このコマンドラインで失敗した場合は、TortoiseSVN などの GUI インターフェースで同じタグ付けを試みてください。 - mc.wordpress.org のフォームからリリースパッケージを作成します。
- Slack で共有する: 「念のため: リリースのリンクをツイートしたり、ソーシャルメディアで共有したりしないでください。時には物事がうまくいかず、パッケージの再構築が必要になることがあります。公式ニュースブログに投稿が掲載されるまでは、リリースは正式なものではありません。」
WordPress.org
- https://wordpress.org/download/releases/ にパッケージが表示されていることを確認します。
- パッケージをダウンロードし、解凍します。同じパッケージであることを確認し、MD5サムをチェックします。
- パッケージをテストします:
- パッケージのテストには2つの方法があります:
- WP-CLI を使ってテストする:
wp core update https://wordpress.org/wordpress-5.8.zip - ベータ版/RC 版を直接ダウンロードする (例: https://wordpress.org/wordpress-5.8.zip)
- WP-CLI を使ってテストする:
- 特に、以下のタイプのインストールとアップデートをテストすると良いでしょう:
- WordPress の新規インストールは正しく動作しますか ? これには、WP-CLI やワンクリックインストーラだけでなく、手動インストールプロセスの実行も含まれます。
- 4.0.33、4.9.18、5.7.2、5.8 RC4、およびその他のバージョンからのアップグレードをテストしてください。
wp-config.phpファイルを削除し、新規インストールをテストします。- シングルサイトとマルチサイト/ネットワーク (サブディレクトリとサブドメインの両方) のインストールをテストします。
- 正しくアップグレードされていますか ? アップグレード時に、
$_old_filesにリストされているファイルは削除されていますか ? - マルチサイトは正しくアップグレードされますか ?
- 最後に、デスクトップとモバイルの以下のユーザーフローが期待通りに動作することを検証すると良いでしょう:
- さまざまなブロックを含む投稿を公開する。
- 投稿にコメントする。
- 新しいプラグイン/テーマをインストールするか、既存のものをアップグレードする。
- サイトの言語を変更する。
- あなたがプラグイン開発者である場合、またはあなたが依存している複雑なプラグインがある場合、それらが正しく動作していることをテストします。
- パッケージのテストには2つの方法があります:
- ダウンロードカウンターの最終スクリーンショットを撮ります。
.config/versions.phpのバージョンを上げます。(デプロイする前に更新通知をテストできるように、WordPress.org のサンドボックス上で行ってください)。- RC 中にブランチに設定されていた場合は、
WP_CORE_DEV_BRANCHをtrunkに戻します。メジャーリリースの場合は、WP_CORE_STABLE_BRANCHを更新します。 WP_CORE_LATEST_RELEASEを更新します。- 新しいデフォルトテーマがある場合は
WP_CORE_NEW_BUNDLED_VERSIONを更新します。これは重要です。 wporg_get_secure_versions()を、Google ウェブマスターツールで使用される API エンドポイントで使用される以前のセキュアな安定版リリースで更新します。- プラグインディレクトリで使用される
wporg_get_version_equivalents()を必要に応じて更新してください。 - これらの変更がデプロイされると、自動アップデートが開始されます – 最後のステップ #9 を参照してください。
- RC 中にブランチに設定されていた場合は、
- 関連するクレジットファイルを更新し、変更をデプロイします。
- リリース用の言語パック、
translate/bin/update-all-core-packs.shでバージョンを上げてビルドします。 - サンドボックスから
deploy-dotorg.sh wporgを実行して、WordPress.org をデプロイします。
世界に伝える
- (リリースビデオを WordPress.TV に投稿します。ただし、公開しないでください。 Twitter や Facebook に公開しないよう、公開ボタンのチェックを外してください)
- wordpress.org/news でお知らせを公開します。Twitter にも自動投稿されます。
- リリース番号ではなく、リリースジャズミュージシャンの名前のみを含めスラッグを更新します。
- HelpHub リリースページを公開します。
- Codex を更新します。
- Codex のバージョンページを確定します。
- 追加:
{{#dotorgredirect:https://wordpress.org/support/wordpress-version/version-6-2/}
- 追加:
- 新しいバージョンで CurrentVersion テンプレートを更新します。
- WordPress バージョンページを更新します。
- 以下を追加します:
{{ ReleaseTableMajor | version = 4.4 | date = December 8, 2015 | musician = Clifford Brown | blog = https://wordpress.org/news/2015/12/clifford/ | db = 35700 }} - 「予定されているバージョン」セクションからバージョンを削除します。
- 以下を追加します:
- PHP の互換性と WordPress のバージョンテーブルを更新します。
- PHPUnit の互換性と WordPress のバージョンを更新します。
- Codex のバージョンページを確定します。
- ダウンロードカウンターを見つめて楽しみましょう。
リリース後
- ブランチのバージョンを
X.Y.1-alpha-$REVNUM-srcに、trunk のバージョンをX.Y+1-alpha-$REVNUM-srcに更新し、対応するpackage.jsonとpackage-lock.jsonの変更も一緒に更新します。次のリリースのリードがコミット権限を持っている場合は、trunk を更新する栄誉が与えられるべきです。6.3リリースのコミット例: https://core.trac.wordpress.org/changeset/55611。 - ナイトリービルドを強制します。(注意: ナイトリービルドではチェックサムは利用できません。WP-CLI は、インストールされているバージョンとアップグレード先のバージョンの両方のチェックサムを取得するので、古いファイルを削除できます)。
- Trac で
trunkバージョンの名前をX.Yに変更し、trunk 用の新しいバージョンを作成します。X.Yのマイルストーンを完成させ、新しいサイクルとX.Y.1の新しいマイルストーンを作成します。これは Trac の管理者が行う必要があります。 - Trac では、前のメジャーに対して未リリースのマイナーマイルストーンがある場合、マイルストーンを新しい
X.Y(すでに解決されX.Yブランチに含まれるチケットの場合) またはX.Y.1(まだ調査や議論が必要なチケットの場合) に更新します。Trac 管理者は未リリースのマイナーマイルストーンを削除してください。 - ドキュメントのさまざまな部分を更新してください:
- make.wordpress.org/core のサイドバーにある現在のリリース。
- make.wordpress.org/core/reports を更新して「次のメジャーリリース」のバージョンを変更します。
注: Gutenberg コードエディターを使用して編集します。そうしないと、ダッシュアイコンが削除されます。 - wordpress.org/about/roadmap と wordpress.org/about/history を更新し、今後のリリースリストから新しいリリースを削除し、ジャズミュージシャンを追加し、リリース日を追加します。注: ページの内容は Meta SVN リポジトリにあります。
- wordpress.org/support/article/history を更新します。
- wordpress.org/support/article/wordpress-versions を更新します。
- 開発サイクルのドキュメント (例: https://make.wordpress.org/core/x-x/)。
- https://wordpress.org/support/ のトップページにある「Getting Started」の最新リリースを更新します。
- https://wordpress.org/support/forum/how-to-and-troubleshooting/ のトップにある固定スレッドを更新します。
- wordpress.org のサンドボックスで
wp devhub parse --url=developer.wordpress.orgを実行します。これで DevHub コードリファレンスのドキュメントが最新の安定版コアリリースを解析するように更新されます。
- Polyglots チームを忘れないでください ! リリース投稿のコードバージョンを #polyglots チャンネルで共有し、彼らが簡単に翻訳できるようにしましょう。リリース投稿をエディターで開き、設定 > すべてのコンテンツをコピーに進みます。Slack の #polyglots チャンネルにスニペットとして貼り付けます。
- リリースの過程で重要なテストを手伝ってくれた人たちを特定し、まだクレジットされていない場合はクレジット API に追加するために登録してください。これは Meta Trac チケットで行うことができます。
- リリースの翌週に:
おめでとうございます ! やり遂げました !
最終更新日: