Jetpack/Release Process
Release Steps
- Create separate, version-labeled tickets for each of the release touch-points
- Once each of the tickets in the tracking bug is completed, create an update request to Atul Varma to push the release live.
Release Touchpoints
- Mozilla Labs Jetpack Sub-domain
- Responsible: Aza Raskin
- Mozilla Labs Main Blog
- Responsible: Aza Raskin or Daniel Buchner
- Jetpack Google Group
- Responsible: Daniel Buchner
- FlightDeck SDK Content
- Responsible: Daniel Buchner
- MDC Documentation
- Responsible: Noelle Murata
- Jetpack Ambassador Materials and Talking-points
- Responsible: Aza Raskin
Build/Package/Push the SDK
These instructions explain the process for building the SDK, packaging it into tarball and zip archives, and pushing it to the distribution server.
The instructions vary slightly for release candidate builds. When building a release candidate (f.e. 0.1rc2), references to the version that are inside the packages must refer to the final version (0.1), so the packages can be released as the final version without making any code changes. References to the version that are outside the packages, however, must refer to the release candidate version (0.1rc2), so it can be differentiated from the final release.
Specifically, the static-files/index.html file inside the packages must refer to the final version, but the changeset from which the packages are built must be tagged with the release candidate version, and the package filenames must contain the release candidate version.
The Jetpack SDK uses 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 followed by "rc" and the number of the candidate (0.1rc1, 0.1rc2, etc.).
To build and package the SDK, clone and enter the repository:
hg clone ssh://hg.mozilla.org/labs/jetpack-sdk/ jetpack-sdk cd jetpack-sdk
Update the reference to the version in static-files/index.html to the version you are building (or, for a release candidate, the final version), then commit the change:
hg commit -m"update version for next release"
Tag the repository with the version:
hg tag 0.1rc2
Update the reference to the release version in static-files/index.html to the version of the next cycle (unless you have just built a release candidate, in which case leave the version as is), then commit the change:
hg commit -m"update version for next cycle"
Push the changes to the central repository:
hg push
The central repository will automatically build tarball and ZIP archive packages based on the tag you committed and pushed. Download the packages from their tag-based location in the archive subdirectory of the central repository:
https://hg.mozilla.org/labs/jetpack-sdk/archive/0.1rc2.tar.gz https://hg.mozilla.org/labs/jetpack-sdk/archive/0.1rc2.zip
The packages you download will have "jetpack-sdk-" prepended to them, e.g. jetpack-sdk-0.1rc2.tar.gz and jetpack-sd-0.1rc2.zip.
Push the packages to the staging server:
scp jetpack-sdk-0.1rc2.tar.gz jetpack-sdk-0.1rc2.zip stage.mozilla.org:/pub/mozilla.org/labs/jetpack/
The packages should now be available on the distribution server:
https://ftp.mozilla.org/pub/mozilla.org/labs/jetpack/jetpack-sdk-0.1rc2.tar.gz https://ftp.mozilla.org/pub/mozilla.org/labs/jetpack/jetpack-sdk-0.1rc2.zip