Firefox/Go Faster/Release Process
From MozillaWiki
This page describes the canonical process for releasing a system add-on.
Terminology
- System Add-on
- A Firefox add-on built-in to Firefox itself that ships with it and is enabled by default.
- Live Release
- An update to a system add-on that occurs outside of the RapidRelease process. Unlike the release trains, live releases can happen at any time. These are pushed out to users by Balrog.
Normal Release
A normal release of a system add-on rides the trains and is sent to users along with a normal Firefox release.
- Merge any changes for the release to mozilla-central. System add-on code for Firefox desktop lives in browser/extensions. Add-ons that store their source code in a standalone repository typically tag a release and merge the changes all at once.
- Optionally, uplift your changes to Aurora or Beta. The standard uplift process applies, including QA and Release Management approval.
Live Release
A live release can target a specific Firefox version, platform, build, etc. Note, however, that users that do not match a live release will be given the version of your system add-on that shipped with their current Firefox version. This means that users with a newer version of your add-on due to a live release will be downgraded if they are no longer matched by your targeting.
It's generally a good idea to merge your changes to mozilla-central and get them uplifted before performing a live release.
- Generate an XPI for the version of your system add-on that you wish to release.
- File a Cloud Services bug asking for your XPI to be signed with the System Add-on signing key. Make sure to attach the XPI to the bug.
- Upload the signed XPI to archive.mozilla.org. System add-ons are stored in the
/pub/system-addons/
directory. - Create a release in Balrog pointing to the XPI that you just uploaded.
- Create a rule in Balrog on a testing channel that will serve up your new release.
- Obtain approval from QA and Release Management to deploy a new live release for your add-on. QA will need to know the testing channel you used in order to test the update process.
- Modify the Balrog rule to be sent out to the actual channel you wish to target (usually release).