This document describes the process by which versions of the Add-on SDK are released. For information about the process by which versions of the SDK are developed, see Jetpack/Development Process.

Prepare

Note: many of this step's substeps can be done in parallel.

Clone Checklist

Copy this checklist to a new wiki page at Jetpack/SDK/(VERSION)/Release_Checklist (f.e. Jetpack/SDK/1.2/Release_Checklist), and choose people to fill the Release Manager (RM), Release Engineer (RE), Technical Lead (TL), and Documentation Lead (DL) roles. Use the checklist to track the status of the release.

Task	Owner	Status
Prepare
Clone Checklist	RM
Merge Master to Stabilization	RE
File Tracking Bug	RM
Notify Relevant Parties
Community	RM
Product Planning	RM
PR	RM
Spin Test Builds	RE
Stabilize Codebase	TL
Draft Release Announcement	RM
Write Release Notes	DL
Choose Candidate	RM
Push Docs	DL
Release
Bless Candidate Build	RE
Update Latest Builds Redirect	RE
Update Latest Docs Redirect	DL
Publish Release Announcement	RM
Merge Stabilization to Release	RE
Notify Community	RM
Bask	RM
Review	RM

Merge Master to Stabilization

Clone the canonical repository, and enter the clone's working directory:

git clone git@github.com:mozilla/addon-sdk.git
cd addon-sdk

Merge the master (development) branch to the stabilization branch:

git checkout stabilization
git merge master

If there are merge conflicts, resolve them, then commit the merge.

Change back to the master branch:

git checkout master

Set JPCV (Jetpack Current Version) to the current version identifier on the master branch (f.e. 1.2a0):

export JPCV=`cat .version`

Set JPNV (Jetpack Next Version) to the next version identifier on the master branch (f.e. 1.3a0):

export JPNV=(NEXT VERSION)

Change the version identifier on the master branch for the next development cycle:

find .version * -type f -exec perl -pi -e "s/${JPCV}/${JPNV}/g" {} \;

Verify that the version identifiers were changed correctly. In particular, make sure the find/replace command didn't modify strings that aren't SDK version identifiers but look similar to them (f.e. a version identifier in the jQuery library).

Commit the changes:

git commit -a -m"update SDK version to ${JPNV} for next development cycle"

Change the Firefox minVersion/maxVersion compatibility identifiers on the master branch to the values on the Firefox aurora/central branches.

Commit the changes:

git commit -a -m"update Firefox minVersion/maxVersion to aurora/central versions of Firefox"

Check out the stabilization branch:

git checkout stabilization

Change the Firefox minVersion/maxVersion compatibility identifiers on the stabilization branch per the Jetpack/Development Process.

Commit the changes:

git commit -a -m"update Firefox minVersion/maxVersion to anticipated current/next versions of Firefox"

Push the changes to the canonical repository:

git push origin master stabilization

File Tracking Bug

File a bug to track the release using this release tracking bug template.

Notify Relevant Parties

Community

Notify project participants in the discussion forum. Mention the tentative release date, and reference the tracking bug and release checklist.

Product Planning

Notify product planners via their weekly meeting.

PR

Notify the Mozilla PR team (press@mozilla.com).

(Myk: Do we still need to do this? PR sits in the product planning meetings.)

Spin Test Builds

To ensure the release meets our quality standards, spin test builds and distribute them to testers. Do this at least weekly during the stabilization period, spinning beta builds initially and one or more release candidate builds ultimately.

Clone the canonical repository, and enter the clone's working directory, and check out the stabilization branch:

git clone git@github.com:mozilla/addon-sdk.git
cd addon-sdk
git checkout stabilization

Set JPCV (Jetpack Current Version) to the current version (f.e. 1.2b1):

export JPCV=`cat .version`

Set JPNV (Jetpack Next Version) to the next version being built (f.e. 1.2b2):

export JPNV=(NEXT VERSION)

If building a beta, set JPFV (Jetpack Final Version) to JPNV:

export JPFV=${JPNV}

Otherwise, when building a release candidate, set JPFV to the version being released (f.e. 1.2):

export JPFV=(FINAL VERSION)

Change the version identifier in source files to the one for the test build:

find .version * -type f -exec perl -pi -e "s/${JPCV}/${JPFV}/g" {} \;

Verify that the version identifiers were changed correctly. In particular, make sure the find/replace command didn't modify strings that aren't SDK version identifiers but look similar to them (f.e. a version identifier in the jQuery library).

Commit the changes:

git commit -a -m"update SDK version to ${JPFV} for next test build"

Tag the repository with the test version:

git tag ${JPNV}

Create a tarball and a ZIP archive:

git archive --format=zip --output addon-sdk-${JPNV}.zip --prefix addon-sdk-${JPFV}/ ${JPNV}
git archive --format=tar --output addon-sdk-${JPNV}.tar --prefix addon-sdk-${JPFV}/ ${JPNV}
gzip addon-sdk-${JPNV}.tar # makes addon-sdk-${JPNV}.tar.gz

Note: a beta expands to a directory whose name contains the test version (f.e. addon-sdk-1.2b2), but a candidate expands to a directory whose name contains the final version (f.e. addon-sdk-1.2), so we can bless a candidate simply by renaming its tarball/ZIP archive.

Copy the tarball/ZIP archive to the distribution server:

scp addon-sdk-${JPNV}.tar.gz addon-sdk-${JPNV}.zip stage.mozilla.org:/pub/mozilla.org/labs/jetpack/

Verify that the tarball/ZIP archive is ready for distribution by running integration checks on it:

mkdir TEST_ZIP && cd TEST_ZIP && python ../bin/integration-scripts/integration-check --url https://ftp.mozilla.org/pub/mozilla.org/labs/jetpack/addon-sdk-${JPNV}.zip
cd ..
mkdir TEST_TGZ && cd TEST_TGZ && python ../bin/integration-scripts/integration-check --url https://ftp.mozilla.org/pub/mozilla.org/labs/jetpack/addon-sdk-${JPNV}.tar.gz
cd ..

Note: you may need to set the --binary flag to the location of the binary of Firefox against which you want to test the build.

Push the stabilization branch and the tag to the canonical repository:

git push origin stabilization ${JPNV}

Notify testers about the build via a post to the discussion forum. Have them run automated and manual tests (including submitting generated XPIs to the AMO test server) and report any bugs they discover.

Stabilize Codebase

Land stabilizing changes on the master branch.

Note: because of conflicts due to incompatible SDK and Firefox minVersion/maxVersion changes between the stabilization and master branches, do not land stabilizing changes on the stabilization branch and merge that branch to master. In the future, we may resolve the conflicts and do this.

Periodically generate a list of changes between the master and stabilization branches:

git rev-list --left-right --boundary --pretty=oneline --cherry-pick master...stabilization

Identify stabilizing changes landed on the master branch, and cherry-pick them to the stabilization branch:

git cherry-pick -x (REVISION ID)

Draft Release Announcement

Draft a release announcement blog post for the Add-ons Blog.

To draft the post, access the blog's Wordpress admin page and go to Posts > Add New. Use previous release posts as a template for your new one. Make sure to include a  element to reduce the initial size of the post, and put the post into the developers, jetpack, general, and releases categories.

After drafting the post, share it with other folks who can help edit it, such as the project's marketing manager.

Note: don't publish the post in this step. That should happen in the Release step.

Write Release Notes

Release notes live on the wiki at /Labs/Jetpack/SDK/Release_Notes/(VERSION) (e.g. /Labs/Jetpack/SDK/Release_Notes/1.2). Create a page for the release notes, using the previous release's notes as a template, and include important information about the release in the notes. Mention the issues raised/addressed in each resolved bug that was fixed in the release and has been tagged with the relnote keyword. Also mention issues in each unresolved bug tagged with the relnote keyword.

Reference the release notes from the List of Release Notes.

Choose Candidate

Decide to ship a candidate as the final release.

Push Docs

After you have decided to ship a candidate as the final release, generate the docs for the release.

Clone the canonical repository, and enter the clone's working directory, check out the candidate tag, and activate the SDK:

git clone git@github.com:mozilla/addon-sdk.git
cd addon-sdk
git checkout (CANDIDATE VERSION)
source bin/activate

Generate and expand the docs:

cfx sdocs --baseurl="https://addons.mozilla.org/en-US/developers/docs/sdk/(FINAL VERSION)/"
tar xzf addon-sdk-docs.tgz

Clone the docs repository and delete everything it contains (wbamberg: this is evidently a bit mad, but it makes no sense to me to pretend that this is a new revision, since it's generated):

git clone git@github.com:mozilla/addon-sdk-sdocs.git
cd addon-sdk-sdocs
rm -rf *
git rm *

Copy the docs to the docs repository, commit the changes, tag the revision as (CANDIDATE VERSION)-amo (f.e. 1.2rc1-amo), and push the changes to the docs repository:

cp -r ../doc/* .
git add *
git commit -m "add (CANDIDATE VERSION) docset"
git tag -a (CANDIDATE VERSION)-amo -m "tagged (CANDIDATE VERSION) docset"
git push --tags origin master

Ask IT to push the docs to production and update the "latest" redirect to point to the new docs via this docs push bug template.

Note: IT pushes the docs at their earliest convenience, so we can test them, but they update the latest docs redirect on the day of the release.

(Myk: should there be separate bugs for the Push Docs and Update Latest Docs Redirect steps?)

Release

Bless Candidate

Copy the tarball/ZIP archive for the most recent release candidate to files whose names instead contain the final version:

ssh stage.mozilla.org
cd /pub/mozilla.org/labs/jetpack/
export JPCV=(CANDIDATE VERSION)
export JPFV=(FINAL VERSION)
cp addon-sdk-${JPCV}.zip addon-sdk-${JPFV}.zip
cp addon-sdk-${JPCV}.tar.gz addon-sdk-${JPFV}.tar.gz

Update Latest Builds Redirect

Use a text editor like vi or emacs to update the /pub/mozilla.org/labs/jetpack/.htaccess file on ftp.mozilla.org to redirect the "latest" symlinks to the new release, making the content of the file look like this:

Redirect 307 /pub/mozilla.org/labs/jetpack/addon-sdk-latest.zip https://ftp.mozilla.org/pub/mozilla.org/labs/jetpack/addon-sdk-(FINAL VERSION).zip
Redirect 307 /pub/mozilla.org/labs/jetpack/addon-sdk-latest.tar.gz https://ftp.mozilla.org/pub/mozilla.org/labs/jetpack/addon-sdk-(FINAL VERSION).tar.gz
Redirect 307 /pub/mozilla.org/labs/jetpack/jetpack-sdk-latest.zip https://ftp.mozilla.org/pub/mozilla.org/labs/jetpack/addon-sdk-(FINAL VERSION).zip
Redirect 307 /pub/mozilla.org/labs/jetpack/jetpack-sdk-latest.tar.gz https://ftp.mozilla.org/pub/mozilla.org/labs/jetpack/addon-sdk-(FINAL VERSION).tar.gz

Test the symlinks to ensure they correctly provide the new release.

Update Latest Docs Redirect

Update the latest docs redirect to point to the new version's docs.

Publish Release Announcement

Access the Add-ons blog's Wordpress admin page and go to Posts. Publish the post you previously drafted.

Note: changes to the blog can take several hours to show up on the site because of server-side caching. To check that the post has been published, add "?(SOME UNIQUE STRING)" to the end of the URL, which bypasses the cache.

Merge Stabilization to Release

Set JPFV to the version being released (f.e. 1.2):

export JPFV=(FINAL VERSION)

Clone the canonical repository and enter its working directory:

git clone git@github.com:mozilla/addon-sdk.git
cd addon-sdk

Merge the stabilization branch to the release branch:

git checkout release
git merge remotes/origin/stabilization

Tag the release branch (which should point to the commit from which you built the most recent release candidate) with the final version:

git tag ${JPFV}

Push the release branch and tag to the canonical repository:

git push origin release ${JPFV}

Notify Community

Notify the discussion forum about the release. Include a link to the release tag:

https://github.com/mozilla/addon-sdk/tree/(FINAL VERSION)

Bask

Bask in the glow of the latest and greatest release!

Physically or virtually high-five or fist-jab contributors.

Review

Review the release process via a post-mortem, solicitation of feedback in the weekly meeting and discussion forum, and other methods as appropriate. Identify things that went well and we should continue to do, things that went badly that we should do differently next time, and parts of the process that have changed and for which this document needs to be updated. Make changes as appropriate.

Jetpack/Release Process

Contents

Prepare

Clone Checklist

Merge Master to Stabilization

File Tracking Bug

Notify Relevant Parties

Community

Product Planning

PR

Spin Test Builds

Stabilize Codebase

Draft Release Announcement

Write Release Notes

Choose Candidate

Push Docs

Release

Bless Candidate

Update Latest Builds Redirect

Update Latest Docs Redirect

Publish Release Announcement

Merge Stabilization to Release

Notify Community

Bask

Review

Navigation menu

Jetpack/Release Process

Prepare

Clone Checklist

Merge Master to Stabilization

File Tracking Bug

Notify Relevant Parties

Community

Product Planning

PR

Spin Test Builds

Stabilize Codebase

Draft Release Announcement

Write Release Notes

Choose Candidate

Push Docs

Release

Bless Candidate

Update Latest Builds Redirect

Update Latest Docs Redirect

Publish Release Announcement

Merge Stabilization to Release

Notify Community

Bask

Review

Navigation menu

Search