Mozilla Release Checklist

これは、drivers@mozilla.org が、リリース前にやるべきことが正しくなされているか確認する作業を助けたり、リリース作業をどのように実施するかについての荒いアイディアを他のメンバーに明らかにしたりするためのチェックリストです。ビルドチームは恐らく、このリストの一部分を別途持っていると思われます (たぶん、その方がよいでしょう)。

If you have additions or suggestions for this list, please note them at the wiki and one of will migrate appropriate additions from there to here.

なされるべき修正が施されるようにする

• blocking[R]? バグフラグを付与された＝ノーミネートされたバグを検索し、+ か - のいずれかにマークする。
• blocking[R]+ 対象バグのオーナーにバグ修正を働きかける (恐らく、バグの中には修正が近く、本当のblockingとは言えないものも混じっています)。
• talkback データを注視し、関係するバグをノミネートする。
• リリースのためにひとたびツリーが閉じられたら、approval リクエスト (approval[R]? パッチフラグ) を取り扱う。
• メモリリークのようなテスト困難な領域のレグレッションを監視する。

ブランチを作成する

アルファリリースやベータリリースなどではなく) ファイナルリリースである場合、ブランチを作成する必要があります。これは、必要な修正がほぼすべてチェックインされた時点で一度だけ行われます。今こそ本当にリリースするときであると決定する前に、driver はビルドを通じて、高品質であるかどうかユーザからフィードバックを集めます。最終決定する前に、talkback が動作することを確認し、スモークテストとごく少数の追加テストを実行します。

リリースするその時、driver はビルドチームに今こそリリースタグを付けるタイミングであり、ファイナルビルドを作成するときであることを告げます (通常、いくつかの事前警告や不確定性が伴います)。ビルドチームはツリーを引っ張り、ベースタグを (cvs tag -b にて) タグ付けすることで、ブランチを切ります。タグ付けの手引きにはミニブランチについての言及がありますが、必須のものではないことに注意してください。これは、ツリーを引いてくるスクリプトがブランチそれ自身によって更新されるからです。

タグ付けされたファイルは、ビルドスクリプトにより引っ張ってくるもの (詳細) ものだけではありません。以下のものも含まれます。mozilla/other-licenses/libart_lgpl/、 mozilla/tools/trace-malloc/、 mozilla/tools/jprof/、 mozilla/tools/codesighs/、 mozilla/toolkit/、 mozilla/chrome/、 mozilla/other-licenses/branding/、 mozilla/other-licenses/7zstub/、 mozilla/browser/、 mozilla/mail/、 mozilla/composer/ (これに加え、 私が言及し忘れているものがたぶんまだいくつか他にあります)。

以下のコマンドにより、ファイルを追加でチェックアウトします:

cvs co                                \
  mozilla/other-licenses/libart_lgpl/ \
  mozilla/tools/trace-malloc/         \
  mozilla/tools/jprof/                \
  mozilla/tools/codesighs/            \
  mozilla/toolkit/                    \
  mozilla/chrome/                     \
  mozilla/other-licenses/branding/    \
  mozilla/other-licenses/7zstub/      \
  mozilla/browser/                    \
  mozilla/mail/                       \
  mozilla/composer/

ブランチが作成されると、blocking[R] バグのノーミネートフラグが次のリリースのために作成されます。

sysadmin への通知

我々が知名度が上がるにつれ、リリースは、サーバに大量の帯域負荷をかける傾向があります。リリース日が設定されてすぐに(たぶん、一週間かそれ以内に)、sysadmins@mozilla.org へリリースが差し迫っていることを確実に知らせます。これは、適切な帯域が利用可能となるよう準備するためです。特に重要なのは、FTP ミラーネットワークです。ミラーを共有している他のプロジェクトとのバッティングを避けることができます。

バージョン番号の更新

バージョン番号の更新は二度行われなくてはなりません。リリースがトランクから分かれるとき、リリースまでに行われなければなりません。リリース後、また何度か行われなければなりません (例：1.3b から 1.3b+へ)。リリースがトランクから分かれるとき、バージョン番号はブランチとブランチ後のトランクとの両方で更新されなくてはなりません。

• Mozilla バージョン更新:
  • config/milestone.txt と xpfe/bootstrap/macbuild/Contents/Info.plist 中のバージョン番号を更新します。
  • localeVersion をアップデートする。もし、ローカライズによる変更があれば、config/chrome-versions.sh も変更します。これは、一般に、1.x.yのドットリリース以外のすべてのリリースが該当します。
  • 外部テーマに修正が必要になってしまう、重大なテーマの変更が発生した場合、skinVersion (すべてのcontents-region.rdf ファイル skinVersionを検証するためには、LXR とビルドの chrome/chrome.rdf を検索してください)を更新します。
  • 年が変わってからの最初のリリースでは、以下のファイルの copyright の年を増加させます。xpfe/global/resources/locale/en-US/about.xhtml、 toolkit/content/about.xhtml、 browser/locales/en-US/chrome/browser/aboutDialog.dtd、 mail/locales/en-US/chrome/messenger/aboutDialog.dtd、 browser/base/content/credits.xhtml、 mail/locales/en-US/chrome/messenger/credits.html、 browser/app/nsBrowserApp.cpp、 xulrunner/examples/simple/simple.xulapp、 calendar/sunbird/app/nsCalendarApp.cpp、 xpfe/bootstrap/macbuild/Contents/Info.plist、 browser/app/macbuild/Contents/Info.plist.in、 mail/app/macbuild/Contents/Info.plist.in、 xulrunner/app/macbuild/Contents/Info.plist.in、 calendar/sunbird/app/macbuild/Contents/Info.plist.in。
• アプリケーションバージョンの更新:
  • Browser
    • browser/app/module.ver
    • browser/config/version.txt
    • browser/installer/unix/installer.cfg
    • browser/installer/windows/installer.cfg
  • Mail
    • mail/app/module.ver
    • mail/config/version.txt
    • mail/installer/windows/installer.cfg

ファイナルリリースの場合のみ、Debug メニューと QA メニュー、ビルド番号などを削除します。 (詳細は バグ 180823、バグ 163246、バグ 139335 を参照のこと)

リリースビルド作成

リリースするその時、driver はビルドチームに今こそリリースタグを付けるタイミングであり、ファイナルビルドを作成するときであることを告げます (通常、いくつかの事前警告や不確定性が伴います)。ビルドチームはツリーを引っ張り、ベースタグを (タグ付けするファイルにコメントを入れるために 前述内容 を参照のこと) リリースのタグ付け をし、主要プラットフォームに対する必要なビルドを作成します。 (リリースビルドノート を参照のこと) 他のプラットフォームや特定のディストリビューション (例：RPMS) 向けの追加のビルドは貢献されるでしょう。これらのビルドを設置するために。メインリリースのディレクトリの下に、 contrib ディレクトリを作成することを忘れないでください。

(しばしば、実際には順序が逆になります。それは、テスト済みの nightly ビルドのある一組を、リリースだと宣言するケースで (リリースの決断を下すことについては、上述内容参照のこと)、対応するソースコードにタグ付けされます。) この場合、結果としてのビルドはリリースビルドだと宣言される前に、間違いなくテスト済みである必要があります。)

ビルドを作成するとき、ネットワークインストーラーは、抽出・再パッケージもしくはリビルドされなくてはなりません。それは、FTPサイトのリリースディレクトリ参照するためです。

新しいリリースのダウンロード状態把握を開始するために、ログ分析スクリプトを更新します。

リリースのアナウンス

• リリースノートページを執筆し、チェックイン します。
• 次のリリース向けの、blocking[R] バグノーミネートフラグを作成し、現在のリリース向けの blocking[R] と approval[R] フラグを引っ込めます (たぶん、次のリリースへの要望を抜き出した後にです)。
• talkback チームに三大主要プラットフォームのmaster.ini ファイルから識別子を取り出して伝えます。
• ビルドがすべての FTP サーバに行き渡った後、Web ページを更新します:
  • 新しいリリースのアナウンスを news.html に追記する。
  • 新しいバージョンの番号と URL で VARIABLES を更新する。
  • Mozilla リリース時には、releases/index.html と releases/<version>/index.html を更新する。
  • Firefox リリース時には、http://www.mozilla.org/products/firefox/releases/<version>.html を更新し、index.html が参照しているため、httpd.conf を更新します。
  • Thunderbird リリース時には、http://www.mozilla.org/products/thunderbird/releases/<version>.html を更新し、index.html にコピーします。
  • CVS タグ を更新し、最新のリリースタグを追記する。
  • roadmap.html の "actual release" () 欄を更新する。
• (ビルドチームは) FTP の README を更新する。
• ひとたび FTP サーバ上にリリースされると、リリースページのトップページを更新し、Web サイトのスクリプトを再起動する。
• すべてのリンクが正しいか、ビルドがすべての FTP ラウンドロビンマシンに行き渡ったかの二重チェックを行う。
• リリースのアナウンスを n.p.m.announce に投稿する。
• mozillaZine、slashdot、newsforege に投稿する。