Release Process

Go to the Releases page and tag a release from master - e.g. name it v1.0.14 or whatever the current working version is.

This web UI creates both a release page and a git tag. But, this doesn't account for cherry picking—but that could just be done with a manually created tag and a release on github can be created later.

Locally on your dev machine, in the project directory:

git fetch --all
git co production
git reset --hard v1.0.14
git push -f origin production

Watch #testpilot-bots in IRC. Any pushes to the production branch should be detected by Jenkins in Mozilla infra. The bot cloudops-ansible should eventually say:
```
testpilot-addon SnoozeTabs #62 building
testpilot-addon SnoozeTabs #62 deployed
```
If instead the bot says failed, the likely culprit is that the version numbers in package.json and src/manifest.json weren't updated like so - this will cause signing on AMO to fail. Other failures require pinging ops folks for a look at Jenkins logs. Hopefully these failures don't happen with things green on CircleCI, since everything should be already exercised & tested there first.
The updated add-on should be available on S3. I'll usually download it, unzip it, and check manifest.json for the correct version - not necessary, but it was helping my confidence in the deploy process.
(optional) Edit the release on GitHub, manually drag in the downloaded .xpi from step 4 to attach it to the release for future reference. This should probably be automated someday.

Provide feedback