Jetpack/Release Process: Difference between revisions

Jump to navigation Jump to search

Jetpack/Release Process (view source)

Revision as of 23:54, 28 September 2011

1,680 bytes removed ,  28 September 2011
update to reflect current release process
m (moved Labs/Jetpack/Release to Jetpack/Release Process: Jetpack is no longer a Labs project; its pages are moving out of the Labs/ hierarchy; and adding "Process" to the name to make the purpose of this page clearer.)
(update to reflect current release process)
Line 1: Line 1:
This document describes the release process for Add-on SDK.  Also see [[Labs/Jetpack/Process|Development Process]].
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 =
= Prepare =


Release preparation includes both build engineering and marketing/communications tasks, some of which can be done in parallel.
{{note|many of this step's substeps can be done in parallel.}}


== Clone Checklist ==
== Clone Checklist ==


Copy this checklist to a new wiki page at Labs/Jetpack/SDK/(version)/Release (f.e. [[Labs/Jetpack/SDK/1.0b2/Release]]) and use it to track the status of release tasks.
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) ownership roles. Use the checklist to track the status of the release process.


{| class="fullwidth-table"
{| class="fullwidth-table"
Line 20: Line 20:
|-
|-
|      Clone Checklist
|      Clone Checklist
|  
| RM
|  
|  
|-
|-
|      File Tracking Bugs
|      Merge Master to Stabilization
|  
| RE
|  
|  
|-
|-
|      Freeze Tree
|      File Tracking Bug
|  
| RM
|  
|  
|-
|-
Line 35: Line 35:
|  
|  
|-
|-
|          Forum
|          Community
|
| RM
| 
|-
|          Ambassadors
|
|
|-
|          PR and Engagement
|  
|  
|  
|-
|-
|          Product Planning
|          Product Planning
|  
| RM
|  
|  
|-
|-
|          IT
|          PR
|  
| RM
|  
|  
|-
|-
|      Update Credits
|      Spin Test Builds
|  
| RE
|  
|  
|-
|-
|      Create Release Branch
|      Stabilize Codebase
|  
| TL
|  
|  
|-
|-
|      Update Version Identifier
|      Draft Release Announcement
|  
| RM
|  
|  
|-
|-
|      Build/Test Release Candidate(s)
|      Write Release Notes
| DL
|  
|  
|
|-
|-
|      Create Website Updates
|      Choose Candidate
|  
| RM
|  
|  
|-
|-
|      Draft Release Announcement
|      Push Docs
|  
| DL
|  
|  
|-
|-
|      Write Release Notes
| Release
|  
|  
|  
|  
|-
|-
| Release
|      Bless Candidate Build
|  
| RE
|  
|  
|-
|-
|      Bless Candidate
|      Update Latest Builds Redirect
|  
| RE
|  
|  
|-
|-
|      Update Website
|      Update Latest Docs Redirect
|  
| DL
|  
|  
|-
|-
|      Publish Release Announcement
|      Publish Release Announcement
|  
| RM
|
|-
|      Tag Release
|
|  
|  
|-
|-
|      Delete Release Branch
|      Merge Stabilization to Release
|  
| RE
|  
|  
|-
|-
|      Notify Forum
|      Notify Community
|  
| RM
|  
|  
|-
|-
| Bask
| Bask
|  
| RM
|  
|  
|-
|-
| Review
| 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:


== File Tracking Bugs ==
git checkout stabilization
git merge master


File a bug to track code blockers of the release and another to track the overall release.
Change the version identifier on the master branch for the next development cycle:


* [https://bugzilla.mozilla.org/enter_bug.cgi?bug_status=ASSIGNED&assigned_to=myk@mozilla.org&cc=dietrich%40mozilla.com&comment=This%20bug%20tracks%20code%20blockers%20for%20the%20Add-on%20SDK%20X.X%20release.%20%20Ping%20Myk%20or%20Dietrich%2C%20or%20comment%20here%20in%20this%20bug%2C%20to%20nominate%20a%20bug%20to%20block%20the%20release.&product=Add-on%20SDK&component=General&op_sys=All&priority=--&rep_platform=All&short_desc=X.X%20release%20blocker%20bugs code blockers bug template]
git checkout master
* [https://bugzilla.mozilla.org/enter_bug.cgi?bug_file_loc=https%3A%2F%2Fwiki.mozilla.org%2FLabs%2FJetpack%2FSDK%2FX.X%2FRelease&bug_status=ASSIGNED&cc=dietrich%40mozilla.com&comment=We%20should%20release%20Add-on%20SDK%20X.X.%20%20Use%20this%20bug%20to%20track%20tasks%20that%20need%20to%20be%20done%20to%20release%20the%20product%2C%20like%20spinning%20candidate%20builds%20and%20publishing%20a%20blog%20post%20about%20it.%20%20Use%20bug%20(code%20blockers%20bug%20number)%20to%20track%20code%20blockers%20for%20the%20release.&product=Add-on%20SDK&component=General&op_sys=All&rep_platform=All&short_desc=release%20Add-on%20SDK%20X.X&assigned_to=myk@mozilla.org&dependson=(code%20blockers%20bug%20number) release bug template]
find . -type f -exec perl -pi -e 's/(CURRENT VERSION)/(NEXT VERSION)/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).


== Freeze Tree ==
Commit the changes:


Freezing is easy. Just notify Jetpack code contributors that development has been frozen via a post to the forum. The post should specify that the only changes that can be committed to the repository until it thaws are release blockers and low risk fixes that have been approved by the release drivers.
git commit -a -m"update SDK version for next development cycle"


Kill two birds with one stone!  Use the post to notify the forum about the release, as specified in Prepare to Release > Notify Relevant Parties > Notify Forum below.
Check out the stabilization branch:


== Notify Relevant Parties ==
git checkout stabilization


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


Notify Jetpack participants in the [http://groups.google.com/group/mozilla-labs-jetpack discussion forum] about the release. Mention the tentative release date, tracking bug, and release notes. Notify the forum again if the release date changes and when each release candidate becomes available.
Commit the changes:


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


Notify Jetpack ambassadors about the release. Include the same information in the notice sent to the discussion forum.
Push the changes to the canonical repository:


=== PR and Engagement ===
git push origin master stabilization


Contact the Mozilla PR team (press@mozilla.com) as well as the folks in charge of Jetpack engagement on the Engagement team (currently Mayumi Matsuno and Dan Horner) and let them know about the release by emailing them. Tell them the tentative release date.  Note whether this is just another in the regular monthly sequence of releases or a major milestone (which determines whether or not the release is likely to be a PR event).
== File Tracking Bug ==


Notify them again if anything changes (f.e. the release date).
File a bug to track the release using [https://bugzilla.mozilla.org/enter_bug.cgi?assigned_to=dcm%40mozilla.com&bug_file_loc=https%3A%2F%2Fwiki.mozilla.org%2FJetpack%2FSDK%2FX.X%2FRelease_Checklist&bug_status=ASSIGNED&cc=myk%40mozilla.org&cc=dtownsend%40mozilla.com&comment=We%20should%20release%20Add-on%20SDK%20X.X.%0D%0A%0D%0AUse%20this%20bug%20to%20track%20release%20blockers%20and%20the%20release%20checklist%20%3Chttps%3A%2F%2Fwiki.mozilla.org%2FJetpack%2FSDK%2FX.X%2FRelease_Checklist%3E%20to%20track%20release%20tasks.%0D%0A&op_sys=All&product=Add-on%20SDK&rep_platform=All&short_desc=release%20Add-on%20SDK%20X.X this release tracking bug template].


=== Product Planning ===
== Notify Relevant Parties ==


Notify the product delivery team about the release by adding a summary of its goals, status of the release candidates, and tentative release date to the [[Firefox/DeliveryMeetings|weekly meeting]] notes. Attend the weekly meeting and talk about the release.
=== Community ===


=== IT ===
Notify project participants in the [http://groups.google.com/group/mozilla-labs-jetpack discussion forum]. Mention the tentative release date, and reference the tracking bug and release checklist.


IT is responsible for pushing changes to the website (including new versions of the documentation) to production, and they should be notified in advance that such changes are forthcoming, even though they don't actually push the changes until the day of the release.
=== Product Planning ===


To notify them, file an IT request ([https://bugzilla.mozilla.org/enter_bug.cgi?blocked=(release%20bug%20number)&bug_status=NEW&cc=zandr%40mozilla.com&comment=We%20are%20now%20stabilizing%20the%20Add-on%20SDK%20source%20tree%20in%20preparation%20for%20the%20release%20of%20Add-on%20SDK%20X.X.%20%20When%20it%20is%20time%20to%20release%2C%20the%20corresponding%20changes%20to%20its%20website%20should%20be%20pushed%20to%20production%2C%20including%3A%0a%0a1.%20pushing%20the%20new%20version%27s%20docs%20to%20the%20website%3B%0a2.%20updating%20the%20%2Fsdk%2Flatest%2Fdocs%2F%20redirect%20to%20point%20to%20the%20new%20version%27s%20docs%3B%0a3.%20pushing%20the%20files%20in%20the%20changeset%20tagged%20%22website-production%22%20in%20the%20%22website%22%20subdirectory%20in%20the%20repository%20https%3A%2F%2Fhg.mozilla.org%2Flabs%2Fjetpack%20to%20the%20production%20server.%0a%0aNote%3A%20this%20work%20should%20not%20be%20done%20until%20the%20day%20of%20the%20release.%20%20The%20tentative%20release%20date%20is%20currently%20Wednesday%2C%20(Month%20and%20Date).&component=Server%20Operations%3A%20Web%20Content%20Push&op_sys=All&product=mozilla.org&rep_platform=All&short_desc=push%20Add-on%20SDK%20X.X%20website%20changes%20to%20production IT request bug template]), cc:ing ":zandr", to have the website changes pushed to production, including:
Notify product planners via their [[Firefox/Planning|weekly meeting]].


# pushing the new version's docs to the website;
=== PR ===
# updating the /sdk/latest/docs/ redirect to point to the new version's docs;
# pushing the files in the changeset tagged "website-production" in the "website" subdirectory in the repository https://hg.mozilla.org/labs/jetpack to the production server.


Make sure to note that the work shouldn't be done until the day of the release, specify the tentative release date, and update it if it changes.
Notify the Mozilla PR team (press@mozilla.com).


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


Update the Credits page at static-files/md/dev-guide/credits.md to include the names of folks who have contributed to the project since the last release.
== Spin Test Builds ==


== Create Release Branch ==
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 release candidate builds ultimately.


Create a branch in the repository called branch-(version) (f.e. branch-1.0b1):
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
  git clone git@github.com:mozilla/addon-sdk.git
  cd addon-sdk
  cd addon-sdk
  git checkout -b branch-1.0b1
  git checkout stabilization
git push origin branch-1.0b1


== Update Version Identifier ==
Set JPTV (Jetpack Test Version) to the test version being built (f.e. 1.2b1):


Update all references in the code to the version of the product so they reflect the version to be released.
export JPTV=(TEST VERSION)


== Build/Test Release Candidate(s) ==
If building a beta, set JPFV (Jetpack Final Version) to JPTV:


In order to make sure a release meets our quality standards, we build and test one or more release candidates before releasing the final version.
export JPFV=${JPTV}


To build and test a release candidate, start by cloning the canonical repository and entering its working directory:
Otherwise, when building a release candidate, set JPFV to the version being released (f.e. 1.2):


  git clone git@github.com:mozilla/addon-sdk.git
  export JPFV=(VERSION)
cd addon-sdk


Change to the release branch:
Create a tarball and a ZIP archive:


  git checkout branch-1.0b1
  git archive --format=zip --output ~/addon-sdk-${JPTV}.zip --worktree-attributes --prefix addon-sdk-${JPFV}/ HEAD
git archive --format=tar --output ~/addon-sdk-${JPTV}.tar --worktree-attributes --prefix addon-sdk-${JPFV}/ HEAD
gzip ~/addon-sdk-${JPTV}.tar # makes addon-sdk-${JPTV}.tar.gz


Create tarball and ZIP archives whose names include a release candidate identifier but whose directory prefixes (i.e. the directory that will be created when the archives are expanded) do not include a release candidate identifier:
{{note|a beta expands to a directory whose name contains the test version (f.e. addon-sdk-1.2b1), 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.}}


git archive --format=zip --output ~/addon-sdk-1.0b1rc1.zip --worktree-attributes --prefix addon-sdk-1.0b1/ HEAD
Copy the tarball/ZIP archive to the distribution server:
git archive --format=tar --output ~/addon-sdk-1.0b1rc1.tar --worktree-attributes --prefix addon-sdk-1.0b1/ HEAD
gzip ~/addon-sdk-1.0b1rc1.tar # makes addon-sdk-1.0b1rc1.tar.gz


Verify that the builds are ready for distribution by running integration and other checks on them.
scp addon-sdk-${JPTV}.tar.gz addon-sdk-${JPTV}.zip stage.mozilla.org:/pub/mozilla.org/labs/jetpack/


Tag the repository with the release candidate version:
Verify that the tarball/ZIP archive is ready for distribution by running integration checks on it:


  git tag 1.0b1rc1 branch-1.0b1
  mkdir TEST_ZIP && cd TEST_ZIP && python ../bin/integration-scripts/integration-check --url https://ftp.mozilla.org/pub/mozilla.org/labs/jetpack/addon-sdk-${JPTV}.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-${JPTV}.tar.gz
cd ..


Push the tag to the canonical repository:
{{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.}}


git push origin 1.0b1rc1
Tag the repository with the test version:


Push the archives to the staging server:
git tag ${JPTV} stabilization


scp addon-sdk-1.0b1rc1.tar.gz addon-sdk-1.0b1rc1.zip stage.mozilla.org:/pub/mozilla.org/labs/jetpack/
Push the stabilization branch and the tag to the canonical repository:


The packages should immediately become available on the distribution server:
git push origin stabilization ${JPTV}


https://ftp.mozilla.org/pub/mozilla.org/labs/jetpack/addon-sdk-1.0b1rc1.tar.gz
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 [https://preview.addons.mozilla.org/ AMO test server]) and report any bugs they discover.
https://ftp.mozilla.org/pub/mozilla.org/labs/jetpack/addon-sdk-1.0b1rc1.zip


Notify QA, the forum, and other testers about the candidate. Have them run automated & manual tests (including submitting generated XPIs to the [https://preview.addons.mozilla.org/ AMO test server]) and report any bugs they discover.
== Stabilize Codebase ==


Triage reported bugs at least daily, determine which are blockers, and get Jetpack developers to fix those blockers. If any blockers are found during an RC test cycle, spin another RC after those blockers are fixed and get testers to verify the fixes and make sure they didn't cause regressions.
Land stabilizing changes on the master branch.


An additional criteria for build quality is approval of the documentation. The documentation lead, or a Jetpack driver, must sign off on the documentation for a given release candidate to be approved for final release.
{{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.}}


== Create Website Updates ==
Periodically generate a list of changes between the master and stabilization branches:


The [https://jetpack.mozillalabs.com/ Jetpack website] lives at jetpack.mozillalabs.com. Much of its content is release-neutral. For example, links to SDK documentation point to a "latest" redirect that takes you to the latest release version of the docs. And buttons/links to download the SDK packages point to "latest" symlinks that link to the latest release packages.
git rev-list --left-right --boundary --pretty=oneline --cherry-pick master...stabilization


Some content, however, might need updating. For example, the description of the SDK on the home page might change over time as the SDK acquires additional APIs and other functionality.
Identify stabilizing changes landed on the master branch, and cherry-pick them to the stabilization branch:


To update the website, clone its code from the [https://hg.mozilla.org/labs/jetpack/ old Jetpack Prototype repository] (the code lives in the [https://hg.mozilla.org/labs/jetpack/file/tip/website website subdirectory]), change the code as needed, test your changes by loading your local working copy of the code in your browser, commit your changes, tag the changeset with the "website-production" tag (you'll need to specify <tt>-f</tt> to force Mercurial to update the existing tag), and push your changes back to the central repository.
git cherry-pick -x (REVISION ID)


== Draft Release Announcement ==
== Draft Release Announcement ==


Draft a blog post for the [http://blog.mozilla.com/addons/ Add-ons Blog] to announce the release.
Draft a release announcement blog post for the [http://blog.mozilla.com/addons/ 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 '''&lt;!-- more -->''' element to reduce the initial size of the post, and put the post into the '''developers''', '''jetpack''', '''general''', and '''releases''' categories.
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 '''&lt;!-- more -->''' 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.
After drafting the post, share it with other folks who can help edit it, such as the project's marketing manager.
Line 248: Line 244:
== Write Release Notes ==
== Write Release Notes ==


Release notes live on the wiki at /Labs/Jetpack/SDK/Release_Notes/[VERSION] (e.g. /Labs/Jetpack/SDK/Release_Notes/0.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.
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 [[Labs/Jetpack/SDK/Release_Notes|List of Release Notes]].
 
== Choose Candidate ==
 
Decide to ship a candidate as the final release.
 
== Push Docs ==


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


Clone the canonical repository and enter its working directory:
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
  git clone git@github.com:mozilla/addon-sdk.git
  cd addon-sdk
  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/(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 *
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:


Update references to the version in static-files/index.html and other files to the development cycle version, which is the conservative anticipated next release followed by the "pre" suffix (e.g. 1.0b2pre), then commit and push the change:
cp -r ../doc/* .
git commit -a -m"add (CANDIDATE VERSION) docset"
git tag (CANDIDATE VERSION)
git push origin master (CANDIDATE VERSION)


(update references to the version)
Ask IT to push the docs to production and update the "latest" redirect to point to the new docs via this [https://bugzilla.mozilla.org/enter_bug.cgi?bug_severity=normal&cc=wbamberg%40mozilla.com&comment=Please%20update%20the%20documentation%20for%20the%20Add-on%20SDK%20in%20conjunction%20with%20its%20X.X%20release.%0D%0A%0D%0AClone%20the%20docs%20from%20%3Cgit%3A%2F%2Fgithub.com%2Fmozilla%2Faddon-sdk-sdocs.git%3E%2C%20and%20check%20out%20the%20TAG%20tag%2C%20i.e.%3A%0D%0A%0D%0A%20%20git%20clone%20git%3A%2F%2Fgithub.com%2Fmozilla%2Faddon-sdk-sdocs.git%0D%0A%20%20cd%20addon-sdk-sdocs%0D%0A%20%20git%20checkout%20TAG%0D%0A%0D%0AThen%20push%20the%20docs%20to%20%3Chttps%3A%2F%2Faddons.mozilla.org%2Fen-US%2Fdevelopers%2Fdocs%2Fsdk%2FX.X%2F%3E.%0D%0A%0D%0ADo%20this%20at%20your%20earliest%20convenience.%20%20Then%2C%20on%20Tuesday%2C%20MONTH%20DAY%2C%20update%20the%20redirect%20at%20%3Chttps%3A%2F%2Faddons.mozilla.org%2Fen-US%2Fdevelopers%2Fdocs%2Fsdk%2Flatest%2F%3E%20to%20point%20to%20%3Chttps%3A%2F%2Faddons.mozilla.org%2Fen-US%2Fdevelopers%2Fdocs%2Fsdk%2FX.X%2F%3E.%0D%0A&component=Server%20Operations%3A%20Web%20Operations&op_sys=All&product=mozilla.org&rep_platform=All&short_desc=%5BAMO%5D%20update%20SDK%20docs%20for%20X.X%20release docs push bug template].
git commit -a -m"update version for next development cycle"
git push origin master


Notify Jetpack code contributors that development has been thawed via a post to the forum. The post should specify that the repository is open for general checkins and that checkins no longer need driver approval.
{{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.}}


{{note|in theory, you can thaw development any time after the first release candidate, since it's possible to fix release blockers on the branch. In practice, it's better to keep the tree frozen longer to focus the team's attention on release blockers.}}
(Myk: should there be separate bugs for the Push Docs and Update Latest Docs Redirect steps?)


= Release =
= Release =
Line 271: Line 291:
== Bless Candidate ==
== Bless Candidate ==


Copy the archives for the latest release candidate to files without the release candidate identifier in the name:
Copy the tarball/ZIP archive for the most recent release candidate to files whose names instead contain the final version:


  ssh stage.mozilla.org
  ssh stage.mozilla.org
  cd /pub/mozilla.org/labs/jetpack/
  cd /pub/mozilla.org/labs/jetpack/
  cp addon-sdk-1.0b1rc1.tar.gz addon-sdk-1.0b1.tar.gz
export JPTV=(CANDIDATE VERSION)
  cp addon-sdk-1.0b1rc1.zip addon-sdk-1.0b1.zip
export JPFV=(VERSION)
  cp addon-sdk-${JPTV}.zip addon-sdk-${JPFV}.zip
  cp addon-sdk-${JPTV}.tar.gz addon-sdk-${JPFV}.tar.gz
 
== Update Latest Builds Redirect ==


Update the /pub/mozilla.org/labs/jetpack/.htaccess file to redirect the "latest" symlinks to the new release:
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-1.0b1.zip
  Redirect 307 /pub/mozilla.org/labs/jetpack/addon-sdk-latest.zip https://ftp.mozilla.org/pub/mozilla.org/labs/jetpack/addon-sdk-(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-1.0b1.tar.gz
  Redirect 307 /pub/mozilla.org/labs/jetpack/addon-sdk-latest.tar.gz https://ftp.mozilla.org/pub/mozilla.org/labs/jetpack/addon-sdk-(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-1.0b1.zip
  Redirect 307 /pub/mozilla.org/labs/jetpack/jetpack-sdk-latest.zip https://ftp.mozilla.org/pub/mozilla.org/labs/jetpack/addon-sdk-(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-1.0b1.tar.gz
  Redirect 307 /pub/mozilla.org/labs/jetpack/jetpack-sdk-latest.tar.gz https://ftp.mozilla.org/pub/mozilla.org/labs/jetpack/addon-sdk-(VERSION).tar.gz


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


== Update Website ==
== Update Latest Docs Redirect ==


In the bug you filed earlier about pushing the website changes to production, comment that now is the time to do the work and wait for its assignee to do it.
Update the latest docs redirect to point to the new version's docs.


== Publish Release Announcement ==
== Publish Release Announcement ==
Line 295: Line 319:
Access the Add-ons blog's Wordpress admin page and go to Posts. Publish the post you previously drafted.
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.}}
{{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):


== Tag Release ==
export JPFV=(VERSION)


Clone the canonical repository and enter its working directory:
Clone the canonical repository and enter its working directory:
Line 304: Line 332:
  cd addon-sdk
  cd addon-sdk


Tag the most recent commit on the release branch (which should be the one from which you built the most recent release candidate) with the release identifier:
Merge the stabilization branch to the release branch:
 
git tag 1.0b1 remotes/origin/branch-1.0b1
 
Push the tag to the canonical repository:


  git push origin 1.0b1
  git checkout release
git merge remotes/origin/stabilization


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


Clone the canonical repository and enter its working directory:
git tag ${JPFV}


git clone git@github.com:mozilla/addon-sdk.git
Push the release branch and tag to the canonical repository:
cd addon-sdk


Push a request to delete the branch:
git push origin release
git push origin ${JPFV}


git push origin :branch-1.0b1
== Notify Community ==


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


Notify the discussion forum about the release.
https://github.com/mozilla/addon-sdk/tree/(VERSION)


= Bask =
= Bask =


Bask in the glow of the latest and greatest release.
Bask in the glow of the latest and greatest release!
 
For minor releases (every month):
 
* physically high-five or fist-jab local contributors;
* virtually high-five or fist-jab remote contributors.
 
For major milestones (every 6-9 months):


* do everything you do for minor releases;
Physically or virtually high-five or fist-jab contributors.
* celebrate over dinner/drinks with local contributors;
* celebrate over the internet with remote contributors.


= Review =
= Review =


After every release, it's useful to review the process described here and update it as appropriate. This can take the form of a formal post mortem, solicitation of feedback in the regular weekly meeting, or individual review by folks who were involved in the release.
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.
MykMelez
canmove, Confirmed users
2,056

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/352739"

Navigation menu