Release Management/Beta Release Checklist

Draft for a beta release checklist.

Update the calendar

Usually we ship beta 1 at the beginning of the week, then in the second week to the fifth week, ship two betas per week. The last week will be the Release Candidate (RC) version and should be on beta for the week before release.

Check worry list

Use a worry list etherpad to keep track of bugs that should land before each beta cycle and the status of new features. This could be especially useful for handoff to other release managers.

Prep for channel meeting

The release manager who owns the current beta usually runs the channel meeting.

Check approval requests

Good to do these in small batches every day.

Go to build

• Prepare for starting the build by going through approvals the night before.
• Check treeherder to make sure the changeset you want to use looks good. Talk with the sheriffs if you need them to merge more changes. From the time of the merge, treeherder needs at least 3 hours to complete all its tests.
• Prepare the build from ship-it.
• Make sure the changeset you're using for the build looks good on treeherder.
• Make sure to create a new l10n milestone for each beta build.
• Check Tree Status: https://treestatus.mozilla.org/
• Start the build from ship-it.
• Communicate with QE if they should test anything in particular
• Check QE's results the next day
• Release your new beta version (If QE signs off, this happens without RelMan's intervention)
• update [product details]
• add release notes

Set EARLY_BETA_OR_EARLIER

We change a flag for Beta 4 (usually).

• Check out the mozilla-beta repo (this takes over an hour, the first time)
• change the build/defines.sh file to read EARLY_BETA_OR_EARLIER= (unset the flag, from 1 to null)
• commit locally with a useful commit message like this, "Post Beta 4: disable EARLY_BETA_OR_EARLIER a=me"
• push your change directly to mozilla-beta (An exception to the usual Tree Rules

Update PRODUCT DETAILS

• More details at wiki page: Product Details