Extension development for beta
john.bieling at gmx.de
Mon Oct 29 09:51:33 UTC 2018
I think the changes are so drastic, that you have to split up your
Add-On development in two branches anyhow.
The ESR60 branch will have a max version of 60.* and the beta branch
will have a min version of 63.* (or whatever you are developing against)
and the beta branch needs a higher main version number.
Both these version should live side by side on ATN, or am I wrong?
Am 29.10.2018 um 09:37 schrieb Geoff Lankow:
> We have a problem. Actually, a series of problems.
> Firstly. For an extension to run on ESR60, it must be:
> 1. an overlay extension with an install.rdf manifest, or
> 2. a bootstrapped extension with an install.rdf manifest, or
> 3. a WebExtension with a manifest.json
> C is very rare, because ESR60 supports so few of the WebExtension
> APIs. B isn't an issue yet but will become one soon, so I'm ignoring
> it for this conversation.
> For A to run on beta, it must have a manifest.json and /NOT/ have an
> install.rdf manifest. (At this point it's technically a WebExtension
> and we're just lying to the extensions back-end about what it's
> actually doing.)
> This leads to the second problem: it's impossible to have an extension
> that both has an install.rdf and doesn't have an install.rdf.
> Therefore an extension developer cannot make an extension that can run
> on both ESR60 and beta.
> (Side note: I've been trying to make a backport for ESR that can run
> an updated legacy extension, but I'm uncomfortable with the size of
> the changes.)
> The extension developer /could/ make a separate version of their
> extension which is only for beta. Given the other big changes in the
> platform, that's probably the best option anyway, but that takes us to
> problem three: they can't host the beta version of their extension on
> ATN, because ATN no longer has support for development channel
> extensions. I /think/ there's an ugly workaround involving uploading
> versions out-of-order such that the ESR version is the one displayed,
> but I really don't think developers should have to deal with that, or
> would bother. They could also self-host the extension but I think most
> wouldn't want to do that.
> We're left with a bunch of not-very-nice options, as well as all the
> other issues facing extension developers, which I think is just going
> to put a lot of developers off altogether, and we'll lose a large
> fraction of our extensions.
> tb-planning mailing list
> tb-planning at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tb-planning