MozillaReleaseChecklist: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(initial landing)
 
No edit summary
 
(9 intermediate revisions by 5 users not shown)
Line 1: Line 1:
<h1>Mozilla Release Checklist</h1>
This serves as a checklist to make sure we don't miss any community, development, QA, Build, Product team, or partner deliverables as we release this version.


<p>This is a checklist used by <code><a href="http://mozilla.org/roadmap.html#project-management">drivers@mozilla.org</a></code>
It is organized by major functional activity in roughly chronological order. At the end of each bullet is the owner of the checklist item from within 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.  The build
team probably has a separate (and probably better) version of some parts
of this list.</p>


<h2 id="right-fixes">Get the right fixes in</h2>
* Development code freeze - Dev Lead


<ul>
* Initial verification - QA Lead
    <li>Search for bugs nominated with the
** Complete Bug Verification Target - QA Lead
    <code>blocking<i>[R]</i>?</code> bug flag, and mark them
** BFT on one platform - QA Lead
    <code>+</code> or <code>-</code>.</li>


    <li>Encourage owners of <code>blocking<i>[R]</i>+</code> bugs (and
* Complete Regression Testing - QA Lead
    perhaps some bugs that are close but not quite blocking) to fix the
** Examples: All BFTs/FFTs, JS regression test, Security regression test, top sites, top extensions, etc. See Test Plan for details.
    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
* En-US Release Candidates
    leaks.</li>
** Release Prep - Build
</ul>
** en-US Install/start page/Version ID/Update test - QA Lead
* RC Release
** Announce to community: https://intranet.mozilla.org/Firefox:ReleaseNotification
** Watch blogs and news groups


<h2 id="make-branch">Make a branch</h2>
* L10n
** Owner signoff as needed
** Trademark review as needed
** L10n Build - Build
*** Capture the chosen nightly into the candidates directory
*** Package up the locales
** Run Automated [[MozillaQualityAssurance:MetaDiff|MetaDiff]] test - Build
** L10N locale spot checks - QA Lead
** Testing by people with language skills
** Update the shipped-locales file with the final locales and platforms - Project Lead
** Update the [[L10n:Firefox_1.5_Releases|public wiki listing the shipped locales]]


<p>If it's a final release (rather than an alpha or beta release), a
* Announce to partners/distributer - basil
branch needs to be made.  This is done once almost all of the necessary
** Symantec
fixes are in.  Before deciding that it's really time to release, drivers
** McAfee
listen to feedback from people using the builds to make sure that
** Need at least a week notice
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>


<p>When it's time to release, drivers let the build team
* Announce to security group - dveditz
know that it's time to tag the release and make the final builds
** to security and security-announce aliases
(usually with some advance warning with some uncertainty).  The build
** 1-2 weeks out
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.</p>


<p id="what_to_tag">The tagged files are more than just the <a href="unix-details.html#s4">default pull</a> by the build scripts.
* Software Updates
They should also include
** build software update mar files - Build
<code>mozilla/other-licenses/libart_lgpl/</code>,
** setup Bouncer and AUS2 links - Build
<code>mozilla/tools/trace-malloc/</code>,
** Run automated [[MozillaQualityAssurance:Update_Checker|Update Checker]] - Build
<code>mozilla/tools/jprof/</code>,
** Spot check combination of update paths, locales, and platforms - QA Lead
<code>mozilla/tools/codesighs/</code>, <code>mozilla/toolkit/</code>,
<code>mozilla/chrome/</code>,


<code>mozilla/other-licenses/branding/</code>,
* Notify Affiliates
<code>mozilla/other-licenses/7zstub/</code>,
** Mozilla Europe
<code>mozilla/browser/</code>, <code>mozilla/mail/</code>,
*** Tristan Nitot - nitot -at- mozilla-europe.org
<code>mozilla/composer/</code>
*** Peter Van der Beken -  peterv -at- mozilla-europe.org
(and probably some other stuff
*** Pascal Chevrel - pascal.chevrel -at- mozilla-europe.org
that I missed).</p>
** Mozilla Japan
*** Gen Kanai - gen -at- mozilla-japan.org
*** dynamis -at- mozilla-japan.org


<p>The following command will checkout these additional files:</p>
* Vulnerability Notice - dveditz
** Draft to Security Group/Security-anncounce
** Advisories posted on release
** NEW: notify CERT (?)


<pre>cvs co                                \
* Other PR as needed - Product
  mozilla/other-licenses/libart_lgpl/ \
** Web site updates
  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/


</pre>
* Release Notes
** Inputs to cbeard/basil - Dev/QA/Product
** First Draft complete - 
** Review - Dev/QA/Product
** Final release notes -


<p>When the branch is made, create the <code>blocking<i>[R]</i></code>
* Final staging
bug nomination flags for the next release.</p>
** Stage bits - Build
** '''Let IT know about release date 24-48 hrs ahead of time.''' - Project Lead
*** Releases should NOT be scheduled in the morning.
** Version ID/Update path test - QA Lead
** Make update paths/install bits live - Build
*** Coordinate with IT to make sure current versions are pushed to the ''mozilla-current'' rsync module
** Run automated [[MozillaQualityAssurance:Download_Checker|download checker]] - QA
** Test live update/install bits - QA Lead
** Dashboard stats tracking configuration/setup (oremj/webteam)
** Post note to these places to annouce the release;
*** all -at- mozilla.com (so all staff knows)
*** drivers -at- mozilla.org (so drivers outside Mozilla Corp know)
*** mozilla.dev.planning newsgroup
*** mozilla.annouce newsgroup (all product release announcements are expected here)
** Post the [http://www.mozilla.org/news.html Press Release]


<h2 id="version-numbers">Update the version numbers</h2>
* Special partner builds
 
** These are builds with partner specific search codes
<p>The version number updates have to be done twice.  When the release
** The are due within 2 weeks of the main product release
is off the trunk they need to be done before the release, and some need
** Generate builds - Build
to be done again after the release (to make things, e.g.,
** Test the builds - QA
<code>1.3b+</code> rather than <code>1.3b</code>).  When the release is
** Release the builds to the respective vendors - Build
off a branch, the version numbers need to be updated on the branch and
on the trunk after the branch.</p>
 
<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 <a href="http://lxr.mozilla.org/seamonkey/">LXR</a> 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>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>
 
<p>Also, for final releases only, remove the Debug and QA menus, build
number, etc.  (See
<a href="http://bugzilla.mozilla.org/show_bug.cgi?id=180823">bug 180823</a>,
<a href="http://bugzilla.mozilla.org/show_bug.cgi?id=163246">bug 163246</a>, and
<a href="http://bugzilla.mozilla.org/show_bug.cgi?id=139335">bug 139335</a>.)</p>
 
<h2 id="release-builds">Make release builds</h2>
 
<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 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.</p>
 
<p>(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.)</p>
 
<p>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.</p>
 
<p>Update log analysis scripts to start grabbing download stats for the new release.</p>
 
<h2 id="announce">Announce the release</h2>
 
<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>http://www.mozilla.org/products/firefox/releases/&lt;version&gt;.html</code> and change <code>httpd.conf</code> so that index.html points to it</li>
        <li>For Thunderbird releases, update
        <code>http://www.mozilla.org/products/thunderbird/releases/&lt;version&gt;.html</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>

Latest revision as of 19:34, 29 May 2007

This serves as a checklist to make sure we don't miss any community, development, QA, Build, Product team, or partner deliverables as we release this version.

It is organized by major functional activity in roughly chronological order. At the end of each bullet is the owner of the checklist item from within the Release Team.

  • Development code freeze - Dev Lead
  • Initial verification - QA Lead
    • Complete Bug Verification Target - QA Lead
    • BFT on one platform - QA Lead
  • Complete Regression Testing - QA Lead
    • Examples: All BFTs/FFTs, JS regression test, Security regression test, top sites, top extensions, etc. See Test Plan for details.
  • L10n
    • Owner signoff as needed
    • Trademark review as needed
    • L10n Build - Build
      • Capture the chosen nightly into the candidates directory
      • Package up the locales
    • Run Automated MetaDiff test - Build
    • L10N locale spot checks - QA Lead
    • Testing by people with language skills
    • Update the shipped-locales file with the final locales and platforms - Project Lead
    • Update the public wiki listing the shipped locales
  • Announce to partners/distributer - basil
    • Symantec
    • McAfee
    • Need at least a week notice
  • Announce to security group - dveditz
    • to security and security-announce aliases
    • 1-2 weeks out
  • Software Updates
    • build software update mar files - Build
    • setup Bouncer and AUS2 links - Build
    • Run automated Update Checker - Build
    • Spot check combination of update paths, locales, and platforms - QA Lead
  • Notify Affiliates
    • Mozilla Europe
      • Tristan Nitot - nitot -at- mozilla-europe.org
      • Peter Van der Beken - peterv -at- mozilla-europe.org
      • Pascal Chevrel - pascal.chevrel -at- mozilla-europe.org
    • Mozilla Japan
      • Gen Kanai - gen -at- mozilla-japan.org
      • dynamis -at- mozilla-japan.org
  • Vulnerability Notice - dveditz
    • Draft to Security Group/Security-anncounce
    • Advisories posted on release
    • NEW: notify CERT (?)
  • Other PR as needed - Product
    • Web site updates
  • Release Notes
    • Inputs to cbeard/basil - Dev/QA/Product
    • First Draft complete -
    • Review - Dev/QA/Product
    • Final release notes -
  • Final staging
    • Stage bits - Build
    • Let IT know about release date 24-48 hrs ahead of time. - Project Lead
      • Releases should NOT be scheduled in the morning.
    • Version ID/Update path test - QA Lead
    • Make update paths/install bits live - Build
      • Coordinate with IT to make sure current versions are pushed to the mozilla-current rsync module
    • Run automated download checker - QA
    • Test live update/install bits - QA Lead
    • Dashboard stats tracking configuration/setup (oremj/webteam)
    • Post note to these places to annouce the release;
      • all -at- mozilla.com (so all staff knows)
      • drivers -at- mozilla.org (so drivers outside Mozilla Corp know)
      • mozilla.dev.planning newsgroup
      • mozilla.annouce newsgroup (all product release announcements are expected here)
    • Post the Press Release
  • Special partner builds
    • These are builds with partner specific search codes
    • The are due within 2 weeks of the main product release
    • Generate builds - Build
    • Test the builds - QA
    • Release the builds to the respective vendors - Build
Retrieved from "https://wiki.mozilla.org/index.php?title=MozillaReleaseChecklist&oldid=58043"