Releases/Checklist

This is the general release checklist we should use for maintenance releases. We use this checklist to make sure we don't miss any community, development, QA, Build, Product team, or partner deliverables as we release new versions.

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.

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.

Team

• Project lead:
• Security/Dev lead:
• Build lead:
• QA lead:

Checklist

• Meet and schedule release - Entire team
  • Email dev-planning and release-drivers to announce meeting (2 days in advance) - Project lead
  • Have meeting - Led by Project lead

• Decision on release date - Entire team
  • Update Releases page - Project lead
  • Update Releases/PRODUCT&VERSION with proposed schedule - Project lead
  • Email dev-planning and release-drivers with proposed schedule - Project lead

• Triage of blocking/approval requests as needed - Entire team (minus build)
  • Schedule meetings - Project lead
  • Alert developers of upcoming freeze - Project lead

• Development code freeze - Dev lead
  • Email release-drivers when all code is in with formal "Go" - Project lead

• Builds created (all locales) - Build lead
  • Email release-drivers when builds are created - Build lead
  • Email betatesters when builds are created - Project lead

• QA verification - QA Lead
  • QA completes testing and maps it onto their test plan page (usually at PRODUCTNAME:VERSION:Test_Plan on the wiki) - QA Lead
  • When signed off, email release-drivers with notification - QA Lead

• Build snippets on betatest channel - Build lead
  • Email QA lead when finished - Build lead

• Project lead creates beta release notes; staging and live - Project Lead

• QA verifies snippets and website and emails release-drivers when signed off - QA Lead

• "Go" to beta
  • Formal "Go" email sent to release-drivers - Project lead
  • Build snippets pushed to beta channel - Build lead
  • QA verifies snippets on beta channel - QA Lead

• Beta period
  • Announce to release-drivers, m.d.a.firefox, m.announce.prerelease, m.d.planning - Project lead
  • Notify mirrors of beta release - Project lead emails Justin
  • Announce to AV/Firewall venders - Project lead
  • Announce to security group - Security lead
    • to security and security-announce aliases
  • Monitor feedback - QA Lead, Project lead

• Vulnerability notices - Security lead
  • Draft to Security Group/Security-anncounce
  • Notify CERT (as needed)

• Draft release notes - Project lead
  • Confirm release notes with dev lead, QA lead, others as appropriate
  • Stage release notes, other website changes

• Decision to release - Entire team
  • If yes, let IT know 24-48 hours ahead of time - Project lead

• Final Release
  • Push website changes - Project lead
  • Push security advisories - Security lead
  • QA verifies website changes - QA Lead
  • Build pushes to release channel - Build lead
  • QA verifies release channel - QA Lead

• Notify the world - Project lead
  • all -at- mozilla.com (so all staff knows)
  • drivers -at- mozilla.org (so drivers outside Mozilla Corp know)
  • m.dev.planning newsgroup
  • m.announce newsgroup (all product release announcements are expected here)
  • MDC Devnews
  • Post the Press Release