Discontinuing beta versions


(Jorge) #1

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!


(Martin Giger) #2

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)


(Jorge) #3

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.


(Mikhail Khvoinitsky) #4

Is it possible to have an unlisted version with the same ID as the listed one?


(Jorge) #5

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.


(Pete) #6

@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?


(Jorge) #7

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.


(Pete) #8

Thanks Jorge. Let me explain my use case a bit more clearly.

The goal is to have:

  • Release versions hosted on AMO
  • Beta versions signed using web-ext and self-hosted

To make this painless, I’d like:

  1. To be able to sign my self-hosted beta versions through web-ext. Manually uploading them through the web interface is not very convenient.
  2. To use the same manifest for AMO and self-hosted files (currently AMO rejects manifests containing an update_url, it would be much more convenient if it just ignored/removed it). Having to modify manifests for betas is a bit awkward.
  3. Not to need to submit (non-beta) releases twice - just host them on AMO, and have them picked up by both beta and regular users (your previous blog post flagged this as a problem too).

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.


(Jorge) #9

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.


(Pete) #10

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”.


(Jorge) #11

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