Auto-tools/Projects/Mozmill/Release
< Auto-tools | Projects | Mozmill
Releasing Mozmill has a lot of moving parts. Here's how it's done.
Releasing For Real
- Release to Pypi
- Release to AMO
- Release to Mozilla-central
Releasing a Preview Release (aka Release to PyPi)
For previews (beta, alpha, rc etc) it's pretty easy. You just send it up to pypi because bothering the AMO Editors for review of a pre-release addon really wastes their time. The one exception to this is for major releases, it might be good to get AMO editor feedback early. But in general, for these releases, we just go to pypi. It's done like so:
- Bump your version: git checkout -b versionbump (do this from your dev branch for the release)
- Change all the setup.py/install.rdf's to have the proper <blah>rcX version where X is your rc number. For betas, use 'beta' etc. Pretty straightforward.
- Make a bug and attach the patch from 2 for review. This is a good step just to ensure we don't miss anything. Leave that bug open until we release so that you don't have to have a new bug for every silly version bump (i.e. rc1, then rc2 etc)
- Once you have review, commit your change to the development branch.
- Go into each directory (mozrunner/mozmill/jsbridge) and issue the following command: python setup.py sdist upload
Note: For step 5, you'll have to have a key registered with pypi and be listed as a maintainer of the pypi packages in order for the upload step to work. If you need that access for some reason, let harth or ctalbert know.
Release to AMO
- Once you have a final version, cd into mozmill/mozmill/mozmill/extension
- Run: ant -f build.xml (this builds the extension)
- Log into your AMO account (assuming you are an editor on AMO), upload the new extension and fill out the required forms on AMO for it.
Release to Mozilla-central
- Once you have a final version that you've uploaded to Pypi and AMO, tag your git branch: git tag -a -m "<msg>" <releasetag>; git push mozauto <releasetag>, (Or do this before releasing final to pypi and amo, either way there are no more code changes at this point so it doesn't matter).
- Create a diff of this branch against the latest mozilla-central repo (mozmill is in testing/mozmill), file a bug and get this reviewed.
- Make any necessary changes to test manifest (if we are adding new tests as part of this release etc)
- Move over applicable versions of tests from the QA Test Repo, to mozilla-central. Create a diff, attach to the same bug you just used for the source and get Henrik (:whimboo) to review it.
- If there are make file updates for the new version (this is rare) create a patch for those and get it reviewed.
- If there are changes to the buildbot custom steps for mozmill (this is rare) create a diff for those and get it reviewed.
- If there were buildbot custom changes, run all these patches through the auto-tools staging system and verify it's ok.
- If making buildbot changes, hide mozmill tests on the "Firefox" (mozilla-central) tree, land buildbot changes, test all patches against try server. This way we can see that the new code will work with the new buildbot steps. If not making buildbot changes, then you don't need to hide the mozmill tests on the "Firefox" tree, you can simply run them against try server.
- If the try server run comes back green, and no new errors are found, land on mozilla-central.
- Blog, announce, and get some beer.