Closed Bug 961846 (sdk-1.16) Opened 10 years ago Closed 10 years ago

Release Add-on SDK 1.16

Categories

(Add-on SDK Graveyard :: General, defect, P1)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: soeren.hentzschel, Assigned: KWierso)

References

Details

Plase provide a new version of the SDK for developers, so developers can update their addons for Australis.

SDK based addons using the Widget API have a really awful user experience in Australis. There is a new ActionButton API, but it can't be used with the SDK from Github because AMO does not allow unstable SDK versions in addons.

It is not possible to use the new APIs with the downloadable SDK 1.15. Use the ActionButton API and try to compile. You will get the following message:

ModuleNotFoundError: unable to satisfy: require(sdk/ui/button/action)

So addon developers need a new downloadable version of the SDK to use the new APIs. Please provide it ASAP because it's important for Australis that addon developers can use the new APIs and update their addons. The widget APIs works, but it's not very nice with Australis. And the addons should be ready for Australis before Australis is in the Beta channel, the sooner the better…

Thanks!
Which version of Firefox are you testing against?
Firefox 29.0a1

The ActionButton API works, but I need the SDK from Github to generate the XPI file, I can't generate the XPI file with the SDK 1.15 and AMO does not accept my XPI generated with the SDK from Github because it is no stable release of the SDK: "We require add-ons to use release versions of the SDK, not development
builds."
Unfortunately you're right, we're going to have to do another release to tide us over until the new tools come in.
Alias: sdk-1.16
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P1
Summary: Provide SDK with new APIs for Australis → Release Add-on SDK 1.16
Depends on: 958609
Assignee: nobody → evold
Once the blockers are cleared we should release a beta build for testing. Wes, can you handle that?
Flags: needinfo?(kwierso)
After tomorrow (thursday), I'm not going to be available until next Wednesday. If that is okay with your schedule, I can spin up a beta then. 

Re-needinfo me when it's time, I'm probably going to be skimming bugmail until the middle of next week.
Flags: needinfo?(kwierso)
Oops unassigning myself, Wes are you doing this?  I can take it if you'd like.
Assignee: evold → nobody
Flags: needinfo?(kwierso)
(In reply to Erik Vold [:erikvold] [:ztatic] from comment #7)
> Oops unassigning myself, Wes are you doing this?  I can take it if you'd
> like.

I'm gonna be pretty busy with sheriff duty for the foreseeable future, so if you want to do the packaging of it, that'd probably be for the best. If you don't have permissions to upload the final zip/tarballs, you could post them somewhere and I can upload them for you.

General process would be:
Create a "1.16" branch based on the SDK's master branch at whatever point you consider good to base 1.16 on. 
Tag the 1.16 branch with a 1.16 tag, then push the branch and the tag with "git push origin 1.16" and then "git push --tags origin".

Then run the following commands to create the zip/tarball:
git archive --format=zip --output addon-sdk-1.16.zip --prefix addon-sdk-1.16/ 1.16
git archive --format=tar --output addon-sdk-1.16.tar --prefix addon-sdk-1.16/ 1.16
gzip addon-sdk-1.16.tar # makes addon-sdk-1.16.tar.gz

Make sure the version number was picked up by extracting the zip or tarball and run this command:
addon-sdk-1.16/bin/cfx --version
(This should print "Add-on SDK 1.16" followed by a revision id if everything worked.)

If you have permissions to upload to the ftp server, you can do the rest of the release process yourself, otherwise, I can do it:
scp addon-sdk-1.16.tar.gz addon-sdk-1.16.zip stage.mozilla.org:/pub/mozilla.org/labs/jetpack/
(If you don't have permissions, attach the two files here and re-needinfo me and I can do it when I get the chance.)

If you can upload, you'll need to make sure that each of those files has 644 permissions so that people can actually download them from the server.
For me, the commands would be something like this:
ssh stage.mozilla.org
cd ../../pub/mozilla.org/labs/jetpack
chmod 644 addon-sdk-1.16.tar.gz
chmod 644 addon-sdk-1.16.zip
logout

Assuming you can upload and login as above, the final steps would be to verify that the files are accessible and correct, then update the 'latest' redirects to point to them.

Step 1, download the files and run the integration checks (Unsure if this step is really important for us anymore since SDK version and Firefox versions don't match up. Might also need to pass the --binary flag to integration-check with a path to the correct Firefox binary):
mkdir TEST_ZIP && cd TEST_ZIP && python ../bin/integration-scripts/integration-check --url https://ftp.mozilla.org/pub/mozilla.org/labs/jetpack/addon-sdk-1.16.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-1.16.tar.gz
cd ..

Update the 'latest' redirects:
ssh stage.mozilla.org
cd ../../pub/mozilla.org/labs/jetpack
vi .htaccess

Edit the file so each line references 1.16 instead of 1.16, save the changes, quit and logout of the ssh session.

Verify that the symlinks all work by downloading them:
https://ftp.mozilla.org/pub/mozilla.org/labs/jetpack/addon-sdk-latest.zip 
https://ftp.mozilla.org/pub/mozilla.org/labs/jetpack/addon-sdk-latest.tar.gz 
https://ftp.mozilla.org/pub/mozilla.org/labs/jetpack/jetpack-sdk-latest.zip 
https://ftp.mozilla.org/pub/mozilla.org/labs/jetpack/jetpack-sdk-latest.tar.gz



That's pretty much it.
Hrm, those are the steps for the final release. To spin up a beta release, it's pretty much the same process:
Create the 1.16 branch.
Tag it as "1.16b1".
Push the branch and the tag to github.
Run the git archive commands just like comment 8 says except use "1.16b1" in place of "1.16".
Upload to ftp as above (again substituting "1.16b1") or attach them here for me to upload.
chmod the file permissions so people can access them.
Ensure the files are accessible.
Announce the beta and link to the files.

You don't need to update the redirects since they aren't the final release builds.



If you do spin a beta first, then the final release is like comment 8 explained except you already have your 1.16 branch, so you'll just merge in whatever changes are necessary to it and retag it as a new beta or final version, and go from there.
Flags: needinfo?(kwierso)
Assignee: nobody → evold
Flags: needinfo?(dtownsend+bugmail)
We're looking for someone to spin up a beta for 1.16 this week. Who's up for that?
Flags: needinfo?(kwierso)
Flags: needinfo?(evold)
Flags: needinfo?(dtownsend+bugmail)
(In reply to Dave Townsend (:Mossop) from comment #10)
> We're looking for someone to spin up a beta for 1.16 this week. Who's up for
> that?

Wes do you mind doing it? It should be the last one.
Flags: needinfo?(evold)
What are we going to base 1.16 on? Some of the recently landed stuff on the master branch is a bit flaky on TBPL, not sure if it should be based on that.

If someone (Dave/Irakli?) can create the "1.16" branch and put the code that you want in 1.16 onto that branch, I can spin up the beta builds fairly easily.
Flags: needinfo?(rFobic)
Flags: needinfo?(kwierso)
Flags: needinfo?(dtownsend+bugmail)
i think it might be a good idea to align with what is shipping in Firefox 29 (Australis).

that doesn't include the most recent stuff, has been tested (somewhat), and afaikt, australis is one of the main reasons to even release 1.16.
Yes I agree we should probably just use the firefox29 branch when the last couple of fixes have landed in the next day
Flags: needinfo?(rFobic)
I've created the 1.16 branch for the release. Over to Kwierso to create the beta
Assignee: evold → kwierso
Flags: needinfo?(dtownsend+bugmail)
Needinfo-ing myself to make sure I get to this. I'll try to have some beta builds up and ready before tomorrow's jetpack meeting.
Flags: needinfo?(kwierso)
1.16b1 zip and tarball created based on the 1.16b1 tag: https://github.com/mozilla/addon-sdk/tree/1.16b1
https://ftp.mozilla.org/pub/mozilla.org/labs/jetpack/addon-sdk-1.16b1.zip
https://ftp.mozilla.org/pub/mozilla.org/labs/jetpack/addon-sdk-1.16b1.tar.gz

Integration tests hanged for me when I ran them on my Linux VM against the current Nightly build, so I don't know if they're actually working as intended. (Of course, we only need this release for the python bits, so I guess it doesn't really matter if the module tests work...)

Moving needinfo back to Mossop for further testing before we do the final builds.
Flags: needinfo?(kwierso) → needinfo?(dtownsend+bugmail)
Announced to the mailing list, we'll plan to release next week
Flags: needinfo?(dtownsend+bugmail)
Depends on: 988072
No longer depends on: 988072
Current status:

Dave created the checklist for the release: https://wiki.mozilla.org/Jetpack/SDK/Release_Checklist/1.16

Final 1.16 zip and tarball uploaded to ftp, files are downloadable, and latest/ redirects are in place.

I downloaded the final zip and created an Australis API-using extension, and cfx xpi performs without issue (the primary reason for this release). cfx run against non-australis throws an error, but only after Firefox is started (so not part of cfx), and cfx run against Australis works correctly. 

I'm currently running the validator update script, and should have a pull request for getting the updated hashes added fairly soon.
Validator pull request is at https://github.com/mozilla/amo-validator/pull/221 awaiting someone to accept it.
All dependencies are solved, SDK 1.16 is released and works well, so I'll mark this bug as fixed. Thanks!
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.