Confirmed users
396
edits
Jetpack/Release Process: Difference between revisions
→Update AMO Validator
Canuckistani (talk | contribs) |
|||
| (32 intermediate revisions by 2 users not shown) | |||
| Line 7: | Line 7: | ||
== Clone Checklist == | == Clone Checklist == | ||
Click on 'Create' ( below ) to copy this checklist to a new wiki page at Jetpack/SDK/Release_Checklist/VERSION (f.e. [[Jetpack/SDK/Release_Checklist/1.10]]), 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. | |||
<createbox> | |||
align=left | |||
type=create | |||
preload=Jetpack/SDK/TEMPLATE/Release_Checklist | |||
default=1.xx | |||
prefix=Jetpack/SDK/Release_Checklist/ | |||
</createbox> | |||
| | The template for this form is [[Jetpack/SDK/TEMPLATE/Release_Checklist|here]]. | ||
==Past SDK Release checklists== | |||
{{Special:PrefixIndex/Jetpack/SDK/Release_Checklist}} | |||
== Merge Master to Stabilization == | == Merge Master to Stabilization == | ||
| Line 123: | Line 34: | ||
git checkout stabilization | git checkout stabilization | ||
git merge --no-commit master | git merge --no-commit master | ||
# resolve conflicts, if any | # resolve conflicts, if any (don't resolve install.rdf yet!) | ||
git commit -m "merge master into stabilization to start the N.N release cycle" | git commit -m "merge master into stabilization to start the N.N release cycle" | ||
| Line 166: | Line 77: | ||
== File Tracking Bug == | == File Tracking Bug == | ||
File a bug to track the release using [https://bugzilla.mozilla.org/enter_bug.cgi?assigned_to= | File a bug to track the release using [https://bugzilla.mozilla.org/enter_bug.cgi?assigned_to=jgriffiths@mozilla.com&bug_file_loc=https://wiki.mozilla.org/Jetpack/SDK/Release_Checklist/X.X&bug_status=ASSIGNED&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%2FRelease_Checklist/X.X%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]. | ||
== Notify Relevant Parties == | == Notify Relevant Parties == | ||
| Line 180: | Line 91: | ||
=== PR === | === PR === | ||
Notify the Mozilla PR team ( | Notify the Mozilla PR team (communications@mozilla.com). | ||
PR likes to have the email, despite sitting in the planning meetings. | PR likes to have the email, despite sitting in the planning meetings. | ||
| Line 232: | Line 143: | ||
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. (Mention that testers should not try to submit add-ons built from the test builds to AMO, as it won't pass the validator.) | 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. (Mention that testers should not try to submit add-ons built from the test builds to AMO, as it won't pass the validator.) | ||
File a bug in the Builder component to get the test build uploaded to the -dev server. | |||
== Stabilize Codebase == | == Stabilize Codebase == | ||
| Line 396: | Line 309: | ||
./generate_jp_whitelist.sh | ./generate_jp_whitelist.sh | ||
cd ../ | cd ../ | ||
</pre> | |||
Make extra-super sure the pickle file can be git add'ed. If it doesn't show up: | |||
<pre> | |||
rm validator/testcases/jetpack_data.txt.pickle | |||
nosetests</pre> | |||
Then go ahead: | |||
<pre> | |||
git add validator/testcases/jetpack_data.txt | git add validator/testcases/jetpack_data.txt | ||
git add validator/testcases/jetpack_data.txt.pickle | |||
git commit -m "Updated amo-validator with hashes for SDK version x.x.x" | git commit -m "Updated amo-validator with hashes for SDK version x.x.x" | ||
git push origin master</pre> | git push origin master</pre> | ||
| Line 407: | Line 328: | ||
Step 4: The changes are pushed with the regular Thursday AMO push. | Step 4: The changes are pushed with the regular Thursday AMO push. | ||
Step 5: Once the AMO push is done, generate an XPI using the release candidate and validate it using AMO in order to verify that the validator has been updated and is working. | |||
== File Builder bug to push build == | |||
Once the Build has been blessed, we need to ensure that it is made available to Builder users as well. The process seems to be: | |||
* File a bug [https://bugzilla.mozilla.org/enter_bug.cgi?product=addons.mozilla.org|against AMO] with the 'Add-on Builder' component, to add the new version to production. | |||
* In a branch of your forked repo for Flightdeck, run these commands to add the new version as a submodule to the FlightDeck repo, then issue a pull request: | |||
git submodule add git://github.com/mozilla/addon-sdk.git lib/addon-sdk-(VERSION) | |||
cd lib/addon-sdk-(VERSION) | |||
git checkout (VERSION) | |||
cd ../.. | |||
git add lib/addon-sdk-(VERSION) | |||
#Don't forget to update LOWEST_APPROVED_SDK and TEST_SDK in settings.py for the new SDK version! | |||
git add settings.py | |||
* ensure that seanmonstr / zalun / arron accepts the pull request and tags it. IT can then take this tag and complete the deployment. | |||
* get IT[1] to run the 'add sdk' command on -dev, make sure things work. Also, stephend should be pinged to ensure tests pass on -dev with the new revision: | |||
./manage.py add_core_lib addon-sdk-1.x --useversion=1.x | |||
* Schedule a push with IT[1] and push the site | |||
* Run the 'add sdk' command[1] in production | |||
[1] It seems to help to assign a bug to IT (oremj specifically?) to get things done on IT's side, including a description of what needs to be done. | |||
== Update Latest Builds Redirect == | == Update Latest Builds Redirect == | ||
| Line 436: | Line 380: | ||
Update the IRC topic on #jetpack to announce the new release. | Update the IRC topic on #jetpack to announce the new release. | ||
File a bug in the Builder component to get the new release pushed to the production Builder server. | |||
= Bask = | = Bask = | ||
| Line 475: | Line 421: | ||
* git tag NEWRELEASE | * git tag NEWRELEASE | ||
* use 'git archive' to create tarballs | * use 'git archive' to create tarballs | ||
* upload tarballs | * upload tarballs (644 permissions!) | ||
* git checkout stabilization | * git checkout stabilization | ||
* git merge release (this may require conflict-resolution) | * git merge release (this may require conflict-resolution) | ||
| Line 494: | Line 440: | ||
* git merge --ff-only hotfix | * git merge --ff-only hotfix | ||
* git tag NEWRELEASE | * git tag NEWRELEASE | ||
* make+upload tarballs | * make+upload tarballs (644 permissions!) | ||
* git checkout stabilization | * git checkout stabilization | ||
* git merge official/release (and resolve conflicts) | * git merge official/release (and resolve conflicts) | ||
* git push official NEWRELEASE release stabilization | * git push official NEWRELEASE release stabilization | ||
* git branch -D hotfix | * git branch -D hotfix | ||
After you make the hotfix, you'll need to get the hotfix pushed to Builder and update the AMO Validator, as detailed further up this page. | |||