canmove, Confirmed users
2,056
edits
Jetpack/Release Process: Difference between revisions
Jump to navigation
Jump to search
use final release versions inside RC builds so we don't have to make code changes to release them
(added section on building/packaging/pushing the SDK) |
(use final release versions inside RC builds so we don't have to make code changes to release them) |
||
| Line 26: | Line 26: | ||
= Build/Package/Push the SDK = | = 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: | To build and package the SDK, clone and enter the repository: | ||
| Line 33: | Line 39: | ||
cd jetpack-sdk | cd jetpack-sdk | ||
Update the reference to the | 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" | hg commit -m"update version for next release" | ||
Tag the repository with the version: | Tag the repository with the version: | ||
| Line 43: | Line 47: | ||
hg tag 0.1rc2 | hg tag 0.1rc2 | ||
Update the reference to the release version in static-files/index.html to the version of the next cycle ( | 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" | hg commit -m"update version for next cycle" | ||
| Line 55: | Line 59: | ||
https://hg.mozilla.org/labs/jetpack-sdk/archive/0.1rc2.tar.gz | https://hg.mozilla.org/labs/jetpack-sdk/archive/0.1rc2.tar.gz | ||
https://hg.mozilla.org/labs/jetpack-sdk/archive/0.1rc2.zip | 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: | Push the packages to the staging server: | ||
scp 0.1rc2.tar.gz 0.1rc2.zip stage.mozilla.org:/pub/mozilla.org/labs/jetpack/ | 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: | The packages should now be available on the distribution server: | ||
https://ftp.mozilla.org/pub/mozilla.org/labs/jetpack/0.1rc2.tar.gz | https://ftp.mozilla.org/pub/mozilla.org/labs/jetpack/jetpack-sdk-0.1rc2.tar.gz | ||
https://ftp.mozilla.org/pub/mozilla.org/labs/jetpack/0.1rc2.zip | https://ftp.mozilla.org/pub/mozilla.org/labs/jetpack/jetpack-sdk-0.1rc2.zip | ||