Loading…
When we get regular updates via Mozilla/Add-ons? #1410
9 participants
Never underestimate the sleeping pattern of the average Mozilla dev !
0.9.3.5 was submitted on 19th April, and is currently at position 70 of 240.
It's not that the review itself is overly long, it's that you need to wait a long time before it gets reviewed. A recent surge in demand due to the upcoming extension signing requirement has not helped.
I will submit 0.9.4.0 (or more likely 0.9.4.5) as soon as 0.9.3.5 is reviewed, however given that the queue length is currently 240 I wouldn't expect to see it arrive any time soon. Better stick with the github releases, at least until extension signing starts to get in the way.
Okay I got it.
Would it be possible to push updates via github instead, just asking. :)
Thanks.
You mean auto-updating? Not directly through github, no. I think it could be done using ublock.org though, so we may be able to support this in the future. On the other hand, depending on how things turn out with Extension Signing it may well not be worth it (if most users can only install AMO versions)
You definitely could update it through GitHub if you wanted to. YouTube Center add-on does this, for example, with a update.rdf file.
Hmm, interesting. According to what I've read, Firefox requires the update.rdf to be served with content-type application/xml (or application/rdf+xml), and raw.github.com only serves as plain/text (precisely to discourage direct linking). If it's working for YouTube Center then perhaps someone on either side has relaxed the rules a bit.
Quickly testing, its update.rdf file (coming from here) is being delivered with content-type 'text/plain; charset=utf-8', but it is working, at least for myself.
raw.github.com only serves as plain/text
Try https://rawgit.com/YePpHa/YouTubeCenter/master/dist/firefox-update.rdf.
I've knocked together some tooling for generating an update.rdf; the script just dumps it in the dist/build folder at the moment. The next thing would be for the build system to update that file within github (or, if preferred, on ublock.org - just needs the url tweaking in install.rdf to match wherever it is going to be hosted).
@chrisaljoudi What's up with the build system these days? From where I'm looking, the travis page is looking a bit empty...
The march version is now 0.9.1.0.1-signed, so signing is pretty quick. What about pushing a new version to addons.mozilla.org? :P
BTW I do modify the xpi's to ship default settings to the clients, with signing this is no more possible?
The signing for existing published add-ons was done automatically by Mozilla, bypassing any queue or review. There is no point pushing a new version to AMO until the one already in the queue has been reviewed and published - the new version joins at the end of the queue and you just waste all the time spent waiting.
Just signing an add-on which passes the automated verification step should be a quick operation, no queue or manual review required. The queue is only required if you want it published on AMO too.
Yes, if you modify the .xpi then you will need to re-sign it (once your clients are using a version of Firefox that requires it). To do this you would need to create an AMO account and use it to sign your modified version.
There is no point pushing a new version to AMO until the one already in the queue has been reviewed and published - the new version joins at the end of the queue and you just waste all the time spent waiting.
It seems that as long as the latest-uploaded version is shown on the add-on's landing page at AMO, users will receive an automatic update within 1–3 days, regardless of whether the associated 'Add to Firefox' button is green (approved) or yellow (preliminarily reviewed) ... Or at least, this is what my Firefox has been experiencing.
Using uBlock Origin at AMO as an example, I've been automatically receiving recent versions in Firefox, although they still have yellow buttons ("preliminarily reviewed") at the moment:-
- v 0.9.8.2 (30 May 2015) — I received this on 31 May
- v 0.9.8.1.1-signed (27 May 2015) — I received this on 28 May
Right now, v 0.9.8.3 (02 Jun 2015) is not found at AMO (not even at the 'Version History' page), & presumably not uploaded to AMO. So I manually installed this version via GitHub.
Does AMO allow the add-on developer an option to show the latest-uploaded version (or any desired version) on the landing page ?
As I write this, uBlock Origin v 0.9.8.2 is listed on both the landing page & the top of the 'Version History' page. Likewise for v 0.9.8.1.1-signed, when AMO's automatic chute previously pushed this version to my Firefox.
In contrast, uBlock at AMO has been looking like this for ages (... note the version discrepancy on landing page vs. 'Version History' page):-
- Landing Page: v 0.9.1.0.1-signed (13 Mar 2015, yellow button)
- Version History (top): v 0.9.3.5 (19 Apr 2015, yellow button)
And users relying on AMO's automatic update is still stuck with v 0.9.1.0.1-signed.
No, you have no control over what version is shown on the landing page, it is always the latest reviewed version. It will be yellow if preliminary reviewed, and green if full reviewed. So far, uBlock has only ever been preliminary reviewed; we have not requested a full review (as this takes even longer).
I have no idea how uBlock Origin managed to get version 0.9.8.2 reviewed in only a couple of days. Perhaps some friendly reviewer on AMO is a fan and picked it out of the list immediately?
@AlexVallat Yeah, pretty weird.
What's your take on moving uBlock for Firefox to our own hosting? I'd appreciate it if you let me know what the steps to getting there are (I don't know much about the Firefox extension-signing stuff), and I'd be eager to help.
Edit: I did see that you made a branch that seems relevant. I'm just curious as to whether we should setup anything.
I'm not an expert on the new signing thing, but if I understand it correctly, extensions on AMO will be signed automatically and extensions outside of AMO are signed as requested. There don't seem to be obstacles in the way of either. The big downside of the signing thing is that all code must be submitted to Mozilla; it's a calculated tradeoff Mozilla made that increases security at the cost of privacy and autonomy.
@chrisaljoudi I have created a branch with code in it to generate an update.rdf, which I mentioned a bit earlier in this thread. The only essential steps are, I think:
1) Integrate into the build process the generation of an update.rdf file. (This is the work I've done already, but may need to be tweaked for final URLs)
2) Have the build process push the generated rdf file onto a public server. This could be github, or ublock.org - the only requirement is that it be accessible through https, so that's no problem.
We might want to be more selective about whether a build produces an update.rdf or not, I don't know. Would we want only releases, or beta builds too? Or even maintaining two channels, though that would be a pain.
Finally, there is the looming issue of signing. At present, there is no API to sign automatically, so I've no idea what the best way of dealing with this is going to be. At worst, each build would have to be uploaded to AMO, signed, downloaded from AMO and re-uploaded as a github release. I don't see that as very practical, but presumably it's an issue that all externally releasing projects will have so maybe something better will come along before we need to use it.
My suggestion would be to ignore external signing until it becomes an issue.
on the landing page, it is always the latest reviewed version [...] I have no idea how uBlock Origin managed to get version 0.9.8.2 reviewed in only a couple of days.
None of the uBlock Origin releases uploaded to AMO has been fully-reviewed (green button). In fact, v 0.9.8.2 at the landing page is still under preliminary review (yellow button).
uBlock Origin is not a unique case though. It's more like uBlock that seems to be in a rather odd situation at AMO.
The below-appended screenshot shows 2 more examples of my add-ons that always have their latest releases (even though only preliminarily reviewed) pushed to users via AMO's automatic-update service fairly quickly (within 1–3 days). Furthermore, the automatic update proceeds regardless of whether the add-on is enabled or kept mostly disabled.
Why has uBlock stalled & become "dis-synchronized" at AMO though ? When I examine the install.rdf (for instance) for v 0.9.1.0.1-signed (automatically deployed to users) vs.v 0.9.3.5 (users don't receive this), I'm able to see that the project fork occurred sometime in between these 2 releases due to attribution & other related changes.
Hence, my question (as a lay user): Is it because the AMO's automatic-update service is not able to tell that v 0.9.3.5 is still uBlock ?
I submitted uBlock Origin 0.9.7.5 for full review, that is the difference. Then after a while I was given feedback about what needed to be addressed, addressed it, and uploaded a new version with those issues addressed, and it appears that versions uploaded following feedback go in a different queue in such case because they were marked "preliminarily reviewed" pretty fast.
Now I am not sure if I have to re-submit for full review, it says in the dashboard I have to wait 10 days before the next move. I am also not sure if I can now submit a new version without feedback asking me to fix things.
Bottom-line: submit it for full review.
Now I am not sure if I have to re-submit for full review
@gorhill — Your current workflow for uBlock Origin at AMO has been working well in the sense that as a user, I've been receiving automatic updates for the 2 recent releases via AMO (ie. as long as you upload them), even though they are not fully reviewed by Mozilla.
Once 0.9.3.5 is reviewed we could then choose to request a full review for the next version. I don't expect it would happen any time soon, but from what gorhill says it might put us in a better position once it does.
@AlexVallat sounds good!
I'm not sure that GitHub would deliver the update manifest with the right mime-type (maybe it does; I just don't know), but hosting it on ublock.org just like the Safari update manifest sounds just great.
@chrisaljoudi That's what i thought, but some of the earlier comments in this thread indicate that it wouldn't be a problem. Still, we've got ublock.org available too, so i guess whichever is easiest for you to do. Just modify the url in install.rdf to point to wherever update.rdf is hosted.
@AlexVallat for scalability and consistency, let's do uBlock.org (if you don't mind).
@chrisaljoudi I like your idea of using uBlock.org, but won't you have to pay for all that traffic? Do you have an estimate of what it will cost? How will it be funded? Can you afford it? I would hate to see you stuck with a bill you can't afford, and then have to change everything again.
@Gitoffthelawn that's what the donations go to.
@chrisaljoudi If uBlock has a million users (which it should reach in short time, given the rapid rate of growth of the user base), and they all download each update from uBlock.org, how many TB of data would that represent, and what would that traffic cost annually?
@Gitoffthelawn it's already a non-negligible amount because of Safari, but I'd personally rather not go into speculating exact numbers.
@Gitoffthelawn The update rdf file is very small, and there is no need to host the .xpi file on ublock.org too, that can continue to be hosted from github as it is now. I doubt the traffic will be excessive.
@AlexVallat @chrisaljoudi Yes, if you just host the rdf, it will be a small fraction of the traffic, than hosting both it and the xpi. I just hope the project doesn't turn into something like ABP where there is suddenly a need/desire/whatever to start taking money from advertisers.
FYI signing "uBlock My Custom Version" toke 10 days:
Approval Status File (All Platforms) Your add-on has been signed.
Created on June 2, 2015 and changed to Preliminarily Reviewed on June 12, 2015
uBlock My Custom Version 0.9.5.0 given preliminary review.
Your unlisted add-on submission has been approved. However, unlisted add-ons are not updated through addons.mozilla.org, so users who install this file won't be able to automatically update to new versions. We recommend that you set up an update URL, as explained here: http://mzl.la/1L3GNDt
The official version still in review? :P
Wow, this sits here without any development for almost two months and now the Developer Edition has force-downgraded my uBlock to 0.9.1.0.1-signed. There is clearly something gone awry with the signing requests. You are forcing your users away to uBlock Origin. That's very sad.
uBlock Origin get updates frequently, uBlock is still at 0.9.1.0 from March 13, 2015! There is no such LONG review process...
Thank you.