View source for Thunderbird:Doing Releases

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 [[Thunderbird:Doing_Releases/Writing_Release_Notes|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 [https://lists.mozilla.org/listinfo/announce-prerelease] or [https://lists.mozilla.org/listinfo/announce] to approve it (they are moderated).
*** about:mozilla
**** Deb Richardson, deb at mozilla dot com. issued on Mondays, submission deadline Thursday
*** blog!

[[category:Thunderbird|*]]