Thunderbird:Doing Releases

Warning: This page is obsolete

This page is a guide to drivers/QA/build as to what needs doing throughout a alpha/beta/rc release cycle.

The most important thing is communication to developers - not just via the status meeting minutes. Blogs & newsgroup posts are a vital way of communicating with our volunteers who can't attend those meetings.

Start of the Development Cycle (first couple of weeks)

• Ensure dates of String and Code Freeze are known
• Ensure goals of release are agreed and publicised

Middle of Development Cycle

• Keep an eye on blockers & keep lists updated
• Ensure big changes are landing early
• Track major blockers in meetings
• Ensure blockers have owners
• Consider if test days may be needed for major landings

Late Development Cycle (2-3 weeks before code freeze)

• Hold test days
• Drive blockers at meetings and other times
• Blog early about String & Code freeze dates also put them on tinderbox page.
• Set up driving page for the release and link to it from Releases
• Keep an eye out for core problems

String Freeze

• Announce string freeze (update tinderbox page, blog, mozilla.dev.planning, mozilla.dev.apps.thunderbird.

Code Freeze

• Announce code freeze (update tinderbox page, blog, mozilla.dev.planning, mozilla.dev.apps.thunderbird).

Post Code Freeze

• If blockers remain, poke them as necessary - they should be the focus.
• Keep an eye on new bugs being raised
• Aim to keep the code freeze as short as possible
• Once release is cut, hand off to build via the Releases page, documenting the revisions to use (see previous versions of the release pages).

Release Phase

Good communication helps this phase move quicker.

• Start on release notes as soon as release is cut, if not as soon as code freeze starts
  • This gives plenty of time for folks to comment and bugs with the pages to be fixed.
  • Note in alpha 3, we didn't put the announcement into svn until we'd got everything from staging to production and checked it. This gave us a little "safety buffer" in case we noticed anything on the double-check of the production site.
• Link the release notes to a bug (and hence people can comment on the bug).
• Keep an eye on the Releases page, and ensure QA & Build are moving forward.
• Once QA is complete, assess state of release documentation & builds and decide on release date (in association with build).
  • See Build:ReleasePolicy for the time at which releases can be done.
  • Note: MoCo IT need notifying in advance
• Follow the steps on the Releases page.
  • Check announcement text with davida/PR
  • Suggested list for announcements:
    • Website (obviously!)
    • mozilla.dev.planning, mozilla.dev.apps.thunderbird, mozilla.support.thunderbird
      • These can be done in one post.
      • Set follow-up to mozilla.dev.apps.thunderbird (or somewhere appropriate).
    • mozilla.announce.prerelease and/or mozilla.announce
      • Send this post separately, poke the people mentioned at the bottom of [1] or [2] to approve it (they are moderated).
    • about:mozilla
      • Deb Richardson, deb at mozilla dot com. issued on Mondays, submission deadline Thursday
    • blog!