Mozilla Release Checklist

This is a checklist used by [email protected] to help ensure that the right things happen before a release, and to give others a rough idea of how our release process works. The build team probably has a separate (and probably better) version of some parts of this list.

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.

Get the right fixes in

• Search for bugs nominated with the blocking[R]? bug flag, and mark them + or -.
• Encourage owners of blocking[R]+ bugs (and perhaps some bugs that are close but not quite blocking) to fix the bugs.
• Keep an eye on talkback data, and nominate relevant bugs.
• Handle approval requests (the approval[R]? patch flag) once the tree is frozen for the release.
• Look for regressions in difficult-to-test areas such as memory leaks.

Make a branch

If it's a final release (rather than an alpha or beta release), a branch needs to be made. This is done once almost all of the necessary fixes are in. Before deciding that it's really time to release, drivers listen to feedback from people using the builds to make sure that they're good quality, and, before making the final decision, verify that talkback is working and run the smoketests plus a few additional tests.

When it's time to release, drivers let the build team know that it's time to tag the release and make the final builds (usually with some advance warning with some uncertainty). The build team cuts a branch by pulling a tree and tagging a base tag and (with cvs tag -b) a branch tag. Note that the minibranch mentioned on the tagging instructions isn't necessary here, since the pull scripts are updated on the branch itself.

The tagged files are more than just the default pull by the build scripts. They should also include 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/ (and probably some other stuff that I missed).

The following command will checkout these additional files:

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/

When the branch is made, create the blocking[R] bug nomination flags for the next release.

Notify the sysadmins

With our growing popularity, releases tend to cause us LOTs of bandwidth usage on our servers. As soon as a date has been set for the release (and preferably a week or so in advance) be sure to notify [email protected] that a release is pending, so that proper preparations for having bandwidth available can be made. This is especially important for our FTP mirror network so we can avoid potential conflicts with other projects who share the same mirrors.

Update the version numbers

The version number updates have to be done twice. When the release is off the trunk they need to be done before the release, and some need to be done again after the release (to make things, e.g., 1.3b+ rather than 1.3b). When the release is off a branch, the version numbers need to be updated on the branch and on the trunk after the branch.

• Mozilla version updates:
  • update version in config/milestone.txt and xpfe/bootstrap/macbuild/Contents/Info.plist.
  • localeVersion update, if there are localization changes: update config/chrome-versions.sh. This should generally happen for all releases except for 1.x.y dot releases.
  • If significant theme changes have happened that require modifications to external themes, skinVersion update (all contents-region.rdf files - search LXR and build's chrome/chrome.rdf for skinVersion to verify)
  • If this is the first release of the new year, bump the copyright year in 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, and calendar/sunbird/app/macbuild/Contents/Info.plist.in.
• Application version updates:
  • 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

Also, for final releases only, remove the Debug and QA menus, build number, etc. (See bug 180823, bug 163246, and bug 139335.)

Make release builds

When it's time to release, drivers let the build team know that it's time to tag the release and make the final builds (usually with some advance warning with some uncertainty). The build team pulls the tree and tags the release (see above for comments on tagged files) and makes the necessary builds for the major platforms. (See the Mozilla Release Build Notes.) Additional builds will be contributed for other platforms and for specific distributions (i.e., RPMS). Be sure to create a contrib directory under the main release directory so that these builds have a place to go.

(Often this actually happens in reverse. That is, a certain set of nightly builds, which have already been tested (see above, on deciding when to release) are declared to be the release, and then the corresponding source is tagged. If it doesn't happen this way, then the resulting builds definitely need to be tested before they are declared to be the release.)

When making the builds, the network installers need to be extracted and repackaged or rebuilt so that they point to the releases directory on the FTP site.

Update log analysis scripts to start grabbing download stats for the new release.

Announce the release

• Write the release notes page and check it in.
• Create the blocking[R] bug nomination flags for the next release and retire the blocking[R] and approval[R] sets of flags for the current release (possibly after pushing out some of the requests to the next release).
• Send the talkback team the identifiers from the master.ini files of the three major platforms.
• Make web page changes, which should land after the builds are on all the FTP servers:
  • Update the news.html with an announcement of the release.
  • Update VARIABLES with the new version numbers and URLs.
  • For Mozilla releases, update releases/index.html and releases/<version>/index.html
  • For Firefox releases, update https://www.mozilla.org/products/firefox/releases/<version>.html and change httpd.conf so that index.html points to it
  • For Thunderbird releases, update https://www.mozilla.org/products/thunderbird/releases/<version>.html and copy that to index.html
  • Update CVS Tags doc to include the newest release tag.
  • Update the "actual release" field in roadmap.html.
• (Build team) Update the README for FTP.
• Once the release is on the FTP server, commit the changes to the front page and the releases page and restart the website script.
• Double-check that all the links are correct and that the builds have propagated to all the FTP round-robin machines.
• Send the release announcement to n.p.m.announce.
• Submit notes to mozillazine, slashdot and newsforge.