Labs/Jetpack/SDK/0.4/Release: Difference between revisions

From MozillaWiki
< Labs‎ | Jetpack‎ | SDK‎ | 0.4
Jump to navigation Jump to search
(Created page with '= Overview = Jetpack SDK development happens in roughly four week cycles, as described in Development Process, each of which culminates in stabilization…')
 
 
(12 intermediate revisions by 2 users not shown)
Line 1: Line 1:
= Overview =
The individual steps are detailed on the [https://wiki.mozilla.org/Labs/Jetpack/Release Jetpack Release Process page].


Jetpack SDK development happens in roughly four week cycles, as described in [[Labs/Jetpack/Process|Development Process]], each of which culminates in stabilization and release of the codebase. This document describes the release process.
=Jetpack 0.4 Release Checklist=


The overall process is:
{| class="fullwidth-table"
 
|- style="background:#efefef"
# freeze development
| '''Step'''
# prepare to release
| '''Status'''
#* notify relevant parties
| '''Owner'''
#* build/test release candidate(s)
|-
#* create marketing/PR/evangelism materials
| Freeze Development
# thaw development
| {{done|}}
# release
| Myk
# feel good
|-
# review the process
| Prepare to Release
 
| {{done|}}
In general, we freeze on a Tuesday night at 11:59pm, make the first release candidate available the next day, spend about a week stabilizing the code and preparing the materials, and release the following Wednesday. To ensure that the code is well-baked, we release no sooner than a week after the first candidate and two days after the last one.
| Myk/Dietrich
 
|-
We use numerically consecutive versions to denote major releases (0.1, 0.2, etc.). Development cycles use the version of the next release followed by "pre" (0.1pre before 0.1, 0.2pre before 0.2, etc.). Release candidates use the final release version internally (i.e. in all code, documentation, and other files inside the package) and that version followed by "rc" and the number of the candidate (0.1rc1, 0.1rc2, etc.) in references external to the package (e.g. in the names of the packages).
| &nbsp;&nbsp; Notify Relevant Parties &nbsp;&nbsp;
 
| {{done|}}
The rest of this document describes each step in more detail. When following these steps to release a new version, track the non-trivial work being done by filing a meta-bug for the release that depends on individual bugs for each discrete task.
| Myk
 
|-
= Freeze Development =
| &nbsp;&nbsp;&nbsp;&nbsp; Notify Forum &nbsp;&nbsp;&nbsp;&nbsp;
 
| {{done|}}
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.
| Myk
 
|-
= Prepare to Release =
| &nbsp;&nbsp;&nbsp;&nbsp; Notify Ambassadors &nbsp;&nbsp;&nbsp;&nbsp;
 
| {{done|}}
Preparing to release involves doing three different sets of things, which can be done in parallel:
| Myk
 
|-
* notify relevant parties
| &nbsp;&nbsp;&nbsp;&nbsp; Notify PR &nbsp;&nbsp;&nbsp;&nbsp;
* build/test release candidate(s)
| {{done|}}
* create marketing/PR/evangelism materials
| Myk
 
|-
== Notify Relevant Parties ==
| &nbsp;&nbsp;&nbsp;&nbsp; Notify Product Delivery Team &nbsp;&nbsp;&nbsp;&nbsp;
 
| {{done|}}
=== Notify Forum ===
| Myk
 
|-
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.
| &nbsp;&nbsp;&nbsp;&nbsp; Notify IT &nbsp;&nbsp;&nbsp;&nbsp;  
 
| {{done|}}
=== Notify Ambassadors ===
| Myk, {{bug|566945}}
 
|-
Notify Jetpack ambassadors about the release. Include the same information in the notice sent to the discussion forum.
| &nbsp;&nbsp; Build/Test Release Candidate(s) &nbsp;&nbsp;
 
| {{done|}}
=== Notify PR ===
| Myk/Dietrich
 
|-
Contact the Mozilla PR team and let them know about the release by emailing press@mozilla.com. 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).
| &nbsp;&nbsp; Create Marketing/PR/Evangelism Materials &nbsp;&nbsp;
 
|
Notify them again if anything changes (f.e. the release date).
|
 
|-
=== Notify Product Delivery Team ===
| &nbsp;&nbsp;&nbsp;&nbsp; Update Website &nbsp;&nbsp;&nbsp;&nbsp;
 
| {{done|}}
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 if asked to do so.
| Dietrich
 
|-
=== Notify IT ===
| &nbsp;&nbsp;&nbsp;&nbsp; Write Blog Post &nbsp;&nbsp;&nbsp;&nbsp;  
 
| {{done|}}
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.
| Myk
 
|-
To notify them, [https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&format=itrequest&cc=:zandr file an IT request], cc:ing ":zandr", to have the website changes pushed to production, including:
| &nbsp;&nbsp;&nbsp;&nbsp; Write Release Notes &nbsp;&nbsp;&nbsp;&nbsp;
 
| {{done|}}
# pushing the new version's docs to the website;
| All
# 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.
| Thaw Development
 
| {{done|}}
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.
| Myk
 
|-
== Build/Test Release Candidate(s) ==
| Release
 
|
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.
|
 
|-
To build and test a release candidate, start by cloning the repository and entering its working directory:
| &nbsp;&nbsp; Bless Candidate &nbsp;&nbsp;
 
| {{done|}}
hg clone ssh://hg.mozilla.org/labs/jetpack-sdk/ jetpack-sdk
|
cd jetpack-sdk
|-
 
| &nbsp;&nbsp; Update Website &nbsp;&nbsp;
Update references to the version in static-files/index.html and other files to the final version (e.g. 0.3), then commit the change:
| {{done|}}
 
|
hg commit -m"update version for next release"
|-
 
| &nbsp;&nbsp; Update Blog &nbsp;&nbsp;
Tag the repository with both the release candidate version and the final version (e.g. 0.3rc1 and 0.3):
| [not needed]
 
|
hg tag 0.3rc1
|-
hg tag 0.3
| &nbsp;&nbsp; Publish Blog Post &nbsp;&nbsp;
 
| {{done|}}
{{note|you tag the repository with the release candidate version to record which version the release candidate represents, while you tag it with the final version so the name of the directory in the packages is correct.}}
|
 
|-
Push the changes to the central repository:
| &nbsp;&nbsp; Notify Forum &nbsp;&nbsp;
 
| {{done|}}
hg push
|
 
|-
The central repository will automatically build tarball and ZIP archives based on the version tags you created. Download the packages for the '''final version tag''':
| Feel Good
 
| {{in progress|}}
https://hg.mozilla.org/labs/jetpack-sdk/archive/0.3.tar.gz
|
https://hg.mozilla.org/labs/jetpack-sdk/archive/0.3.zip
|-
 
| Review the Process  
The packages you download will have "jetpack-sdk-" prepended to them, e.g. jetpack-sdk-0.3.tar.gz and jetpack-sdk-0.3.zip. Rename the files to reflect the release candidate version:
|
 
|
mv jetpack-sdk-0.3.tar.gz jetpack-sdk-0.3rc1.tar.gz
|}
mv jetpack-sdk-0.3.zip jetpack-sdk-0.3rc1.zip
 
Push the packages to the staging server:
 
scp jetpack-sdk-0.3rc1.tar.gz jetpack-sdk-0.3rc1.zip stage.mozilla.org:/pub/mozilla.org/labs/jetpack/
 
The packages should immediately become available on the distribution server:
 
https://ftp.mozilla.org/pub/mozilla.org/labs/jetpack/jetpack-sdk-0.3rc1.tar.gz
https://ftp.mozilla.org/pub/mozilla.org/labs/jetpack/jetpack-sdk-0.3rc1.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.
 
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.
 
== Create Marketing/PR/Evangelism Materials ==
 
=== Update Website ===
 
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.
 
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.
 
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.
 
=== Write Blog Post ===
 
The [http://mozillalabs.com/jetpack/ Jetpack blog] lives at mozillalabs.com/jetpack. Each release should be accompanied by a blog post that announces and describes the release.
 
To write 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 size of the post when syndicated to the general Mozilla Labs blog, and put the post into the '''Release''' category so the blog can style it appropriately.
 
{{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/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.
 
= Thaw Development =
 
Update references to the version in static-files/index.html and other files to the development cycle version (e.g. 0.4pre), then commit and push the change:
 
hg commit -m"update version for next development cycle"
hg push
 
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|in theory, you can thaw development any time after the first release candidate, since it's possible to branch the tree at that point and fix release blockers on the branch. In practice, it's better to keep the tree frozen longer, both to focus developers' attention on release blockers and to obviate the encumberance of branching. However, as the number of active Jetpack code contributors increases, and if stabilization cycles become longer, it may start to become better to thaw earlier.}}
 
= Release =
 
== Bless Candidate ==
 
Blessing the last release candidate simply entails copying its archives to files with names reflecting the final release and updating the "latest" symlinks to point to those new files:
 
ssh stage.mozilla.org
cd /pub/mozilla.org/labs/jetpack/
cp jetpack-sdk-0.3rc1.tar.gz jetpack-sdk-0.3.tar.gz
cp jetpack-sdk-0.3rc1.zip jetpack-sdk-0.3.zip
rm jetpack-sdk-latest.tar.gz; ln -s jetpack-sdk-0.3.tar.gz jetpack-sdk-latest.tar.gz
rm jetpack-sdk-latest.zip; ln -s jetpack-sdk-0.3.zip jetpack-sdk-latest.zip
 
== Update Website ==
 
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 Blog ==
 
The [http://mozillalabs.com/jetpack/ Jetpack blog] lives at mozillalabs.com/jetpack. Its content (by which I mean the content that surrounds the blog posts, i.e. logos, navigation links, etc.) is release-neutral, so it generally doesn't need changing.
 
If that ever changes, then it will need to be updated. Since there is no way to stage changes to the blog, this will here in the Release step rather than in the Prepare to Release step.
 
{{note|changes to the blog can take several hours to show up on the site because of server-side caching. To check that your changes have been applied, add "?[some unique string]" to the end of the URL, which bypasses the cache.}}
 
== Publish Blog Post ==
 
Access the blog's Wordpress admin page and go to Posts. Publish the post you previously wrote.
 
{{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.}}
 
== Notify Forum ==
 
Notify the discussion forum about the release.
 
= Feel Good =
 
For minor releases (every month):
 
* physically high-five or fist jab local Jetpack contributors;
* virtually high-five or fist jab remote Jetpack contributors.
 
For major milestones (every 6-9 months):
 
* do everything you do for minor releases;
* celebrate over dinner/drinks with local Jetpack contributors;
* celebrate over the internet with remote Jetpack contributors.
 
= Review the Process =
 
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.

Latest revision as of 22:48, 27 May 2010

The individual steps are detailed on the Jetpack Release Process page.

Jetpack 0.4 Release Checklist

Step Status Owner
Freeze Development [DONE] Myk
Prepare to Release [DONE] Myk/Dietrich
   Notify Relevant Parties    [DONE] Myk
     Notify Forum      [DONE] Myk
     Notify Ambassadors      [DONE] Myk
     Notify PR      [DONE] Myk
     Notify Product Delivery Team      [DONE] Myk
     Notify IT      [DONE] Myk, bug 566945
   Build/Test Release Candidate(s)    [DONE] Myk/Dietrich
   Create Marketing/PR/Evangelism Materials   
     Update Website      [DONE] Dietrich
     Write Blog Post      [DONE] Myk
     Write Release Notes      [DONE] All
Thaw Development [DONE] Myk
Release
   Bless Candidate    [DONE]
   Update Website    [DONE]
   Update Blog    [not needed]
   Publish Blog Post    [DONE]
   Notify Forum    [DONE]
Feel Good IN PROGRESS
Review the Process
Retrieved from "https://wiki.mozilla.org/index.php?title=Labs/Jetpack/SDK/0.4/Release&oldid=226323"