Please read the blog post for details:
https://blog.mozilla.org/addons/2018/02/28/discontinuing-support-for-beta-versions/
If you have any questions or comments, this is the best place to post them!
Please read the blog post for details:
https://blog.mozilla.org/addons/2018/02/28/discontinuing-support-for-beta-versions/
If you have any questions or comments, this is the best place to post them!
Right when the initial anouncement mail arrived, I asked about ways to conveniently run your own beta channel as developer: Maintaining your own development channel
Clearly, having an unsigned version of the extension is the most logical way to deal with it, however I’m wondering what is keeping a developer from publishing their beta version as a separate listed extension, like some app developers do on Google Play? (which totally doesn’t include Mozilla with Firefox Nightly)
This may not be allowed by the reviewers, since it could lead to user confusion by having multiple, very similar listings. It would also have the same problem the beta versions feature had, which is that if the developer doesn’t want to keep maintaining the beta channel, users will be stranded there and can’t be automatically moved to the release channel.
Is it possible to have an unlisted version with the same ID as the listed one?
Yes, you can submit listed and self-hosted versions for the same add-on. You just need to change the “Where to host” setting when you upload a new version for the existing add-on.
@jorgev: this doesn’t seem to be supported by web-ext - if the add-on is on amo, it refuses to sign when I include an update URL. It seems this might be fixed by https://github.com/mozilla/web-ext/pull/1250 ?
Assuming this gets fixed, you mentioned the ability to switch users between beta and release channels, and that it wouldn’t be necessary to publish “release” versions to both channels. This sounds like a big improvement, could you please provide some details on how to accomplish this when the release version is published on amo and the beta is self-hosted?
That’s how it should work. Add-ons hosted on AMO can’t have an updateURL
, while self-hosted add-ons generally do.
The main use case I was referring to is when an update channel is no longer being maintained and there’s a need to migrate the users. So, if you wanted to discontinue your self-hosted beta channel, all you need to do is push an update without an updateURL
, which would make all beta users check for updates on AMO and eventually update to the release channel. If, instead of on AMO, your release channel is also self-hosted, what you need to do is push an update with a different updateURL
, pointing to the channel where you want to move users to.
Thanks Jorge. Let me explain my use case a bit more clearly.
The goal is to have:
To make this painless, I’d like:
If neither 2) nor 3) are possible, it will be necessary to sign the release versions twice - once for AMO and once for self-hosting. I suspect this might not be possible if the manifests differ (although I haven’t tried this).
Does that make sense? It would be really useful to have a set of best practices for this now that the AMO beta feature is going away.
You can do 1. 2 and 3 are definitely not possible. Working around 2 should be relatively easy if you have a build script that toggles that line in the manifest and then calls web-ext
. 3 has no way around it, since hosted AMO files will only update to other AMO versions, and there’s no way to tell them apart from “fake” betas.
Understood, thanks Jorge.
One further question: is it possible to release a version (eg. 1.0.0) to both AMO and self-hosted channels?
Or to ask another way: how can I distribute a release to users on my self-hosted beta channel, so they’re up to date with the latest AMO release?
I’ve tried adding the update_url manually and signing it on AMO, but it fails with “version x.x.x already exists”.
Version numbers can’t be repeated, not even on different channels. You can just add something to the existing version number, like “1.0.0b1” to distinguish one from the other