MozillaReleaseChecklist: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(copyright year: additional locations)
(Change this from the list to the nomination page for the list)
Line 1: Line 1:
<p>This is a checklist used by <code>[http://mozilla.org/roadmap.html#project-management drivers@mozilla.org]</code>
The <a href="http://www.mozilla.org/build/release-checklist.html">Mozilla Release Checklist</a> is used by <a href="http://mozilla.org/roadmap.html#project-management">drivers@mozilla.org</a> and the release team to help ensure that the right things happen before a release, and to give others a rough idea of how our release process works.
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.</p>


==Get the right fixes in==
If you would like to see additional items added to the checklist, please note them here and drivers@mozilla.org will periodically evaluate the list, migrating changes over to the official document where appropriate.
 
<ul>
    <li>Search for bugs nominated with the
    <code>blocking<i>[R]</i>?</code> bug flag, and mark them
    <code>+</code> or <code>-</code>.</li>
 
    <li>Encourage owners of <code>blocking<i>[R]</i>+</code> bugs (and
    perhaps some bugs that are close but not quite blocking) to fix the
    bugs.</li>
    <li>Keep an eye on talkback data, and nominate relevant bugs.</li>
    <li>Handle approval requests (the <code>approval[R]?</code> patch
    flag) once the tree is frozen for the release.</li>
 
    <li>Look for regressions in difficult-to-test areas such as memory
    leaks.</li>
</ul>
 
==Make a branch==
 
<p>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.</p>
 
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 <a href="cvs-tag.html">tagging</a> a base tag and (with <code>cvs tag
-b</code>) 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 <a href="unix-details.html#s4">default pull</a> 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 <code>blocking<i>[R]</i></code>
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 the [mailto:sysadmins@mozilla.org sysadmins] 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.,
<code>1.3b+</code> rather than <code>1.3b</code>).  When the release is
off a branch, the version numbers need to be updated on the branch and
on the trunk after the branch.
 
<ul>
    <li>Mozilla version updates:
        <ul>
            <li>update version in <code>config/milestone.txt</code> and
                <code>xpfe/bootstrap/macbuild/Contents/Info.plist</code>.</li>
            <li><code>localeVersion</code> update, if there are localization
                changes: update <code>config/chrome-versions.sh</code>.  This
                should generally happen for all releases except for 1.x.y dot
                releases.</li>
 
            <li><em>If significant theme changes have happened that require
                modifications to external themes</em>,
                <code>skinVersion</code> update (all
                <code>contents-region.rdf</code> files - search [http://lxr.mozilla.org/seamonkey/ LXR] and build's
                <code>chrome/chrome.rdf</code> for <code>skinVersion</code> to
                verify)</li>
 
            <li>If this is the first release of the new year, bump the
                copyright year in
                <code>xpfe/global/resources/locale/en-US/about.xhtml</code>,
                <code>toolkit/content/about.xhtml</code>,
                <code>browser/locales/en-US/chrome/browser/aboutDialog.dtd</code>,
                <code>mail/locales/en-US/chrome/messenger/aboutDialog.dtd</code>,
 
                <code>browser/base/content/credits.xhtml</code>,
                <code>mail/locales/en-US/chrome/messenger/credits.html</code>,
 
                <code>browser/app/nsBrowserApp.cpp</code>,
                <code>xulrunner/examples/simple/simple.xulapp</code>,
                <code>calendar/sunbird/app/nsCalendarApp.cpp</code>,
 
                <code>xpfe/bootstrap/macbuild/Contents/Info.plist</code>,
                <code>browser/app/macbuild/Contents/Info.plist.in</code>,
                <code>mail/app/macbuild/Contents/Info.plist.in</code>,
                <code>xulrunner/app/macbuild/Contents/Info.plist.in</code>,
                and <code>calendar/sunbird/app/macbuild/Contents/Info.plist.in</code>.
            </li>
 
        </ul>
    </li>
    <li>Application version updates:
        <ul>
            <li>Browser
                <ul>
                    <li>browser/app/module.ver</li>
                    <li>browser/config/version.txt</li>
                    <li>browser/installer/unix/installer.cfg</li>
 
                    <li>browser/installer/windows/installer.cfg</li>
                </ul>
            </li>
            <li>Mail
                <ul>
                    <li>mail/app/module.ver</li>
                    <li>mail/config/version.txt</li>
                    <li>mail/installer/windows/installer.cfg</li>
 
                </ul>
            </li>
        </ul>
    </li>
</ul>
 
Also, for final releases only, remove the Debug and QA menus, build
number, etc.  (See
[https://bugzilla.mozilla.org/show_bug.cgi?id=180823 bug 180823],
[https://bugzilla.mozilla.org/show_bug.cgi?id=163246 bug 163246], and
[https://bugzilla.mozilla.org/show_bug.cgi?id=139335 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 <a href="cvs-tag.html">tags the release</a> (see <a href="#what_to_tag">above</a> for comments
on tagged files) and makes the necessary builds for the major platforms.
(See the <a href="release-build-notes.html">release build notes</a>.)
Additional builds will be contributed for other platforms and for
specific distributions (i.e., RPMS). Be sure to create a <code>contrib</code> 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==
 
<ul>
    <li>Write the release notes page and <a href="../README-cvs.html">check it in</a>.</li>
 
    <li>Create the <code>blocking<i>[R]</i></code> bug nomination flags
    for the next release and retire the <code>blocking[R]</code> and
    <code>approval[R]</code> sets of flags for the current release
    (possibly after pushing out some of the requests to the next
    release).</li>
    <li>Send the talkback team the identifiers from the master.ini files of
    the three major platforms.</li>
    <li>Make web page changes, which should land after the builds are on
    all the FTP servers:
    <ul>
 
        <li>Update the <a href="../news.html"><code>news.html</code></a> with
        an announcement of the release.</li>
        <li>Update <code>VARIABLES</code> with the new version numbers and URLs.</li>
        <li>For Mozilla releases, update <a href="../releases/"><code>releases/index.html</code></a> and
        <code>releases/&lt;version&gt;/index.html</code></li>
 
        <li>For Firefox releases, update
        <code><nowiki>http://www.mozilla.org/products/firefox/releases/&lt;version&gt;.html</nowiki></code> and change <code>httpd.conf</code> so that index.html points to it</li>
        <li>For Thunderbird releases, update
        <code><nowiki>http://www.mozilla.org/products/thunderbird/releases/&lt;version&gt;.html</nowiki></code> and copy that to <code>index.html</code></li>
 
        <li>Update <code><a href="../releases/cvstags.html">cvstags.html</a></code> doc
        to include the newest release tag.</li>
        <li>Update the "actual release" field in <a href="../roadmap.html">roadmap.html</a>.</li>
    </ul></li>
    <li>(Build team) Update the README for FTP.</li>
    <li>Once the release is on the FTP server, commit the changes
        to the front page and the releases page and restart the website
        script.</li>
 
    <li>Double-check that all the links are correct and that
        the builds have propagated to all the FTP round-robin
        machines.</li>
    <li>Send the release announcement to n.p.m.announce.</li>
    <li>Submit notes to mozillazine, slashdot and newsforge.</li>   
</ul>

Revision as of 20:21, 22 March 2005

The <a href="http://www.mozilla.org/build/release-checklist.html">Mozilla Release Checklist</a> is used by <a href="http://mozilla.org/roadmap.html#project-management">drivers@mozilla.org</a> and the release team to help ensure that the right things happen before a release, and to give others a rough idea of how our release process works.

If you would like to see additional items added to the checklist, please note them here and drivers@mozilla.org will periodically evaluate the list, migrating changes over to the official document where appropriate.

Retrieved from "https://wiki.allizom.org/index.php?title=MozillaReleaseChecklist&oldid=4889"