Extension development for beta

John Bieling john.bieling at gmx.de
Mon Oct 29 09:51:33 UTC 2018


Hi Geoff,

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?

John


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.
>
> GL
>
>
> _______________________________________________
> tb-planning mailing list
> tb-planning at mozilla.org
> https://mail.mozilla.org/listinfo/tb-planning

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20181029/df73cf99/attachment-0001.html>


More information about the tb-planning mailing list