<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<tt>Hi Geoff,<br>
<br>
I think the changes are so drastic, that you have to split up your
Add-On development in two branches anyhow. <br>
<br>
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. <br>
<br>
Both these version should live side by side on ATN, or am I wrong?<br>
<br>
John<br>
</tt><br>
<br>
<div class="moz-cite-prefix">Am 29.10.2018 um 09:37 schrieb Geoff
Lankow:<br>
</div>
<blockquote type="cite"
cite="mid:76a9de72-c407-8f8a-efd4-f961659a8f52@thunderbird.net">
<p>We have a problem. Actually, a series of problems.</p>
<p>Firstly. For an extension to run on ESR60, it must be:</p>
<ol type="A">
<li>an overlay extension with an install.rdf manifest, or</li>
<li>a bootstrapped extension with an install.rdf manifest, or<br>
</li>
<li>a WebExtension with a manifest.json</li>
</ol>
<p>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.</p>
<p>For A to run on beta, it must have a manifest.json and <i>NOT</i>
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.)</p>
<p>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.</p>
<p>(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.)</p>
<p>The extension developer <i>could</i> 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 <i>think</i>
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.</p>
<p>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.</p>
<p>GL<br>
</p>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
tb-planning mailing list
<a class="moz-txt-link-abbreviated" href="mailto:tb-planning@mozilla.org">tb-planning@mozilla.org</a>
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/tb-planning">https://mail.mozilla.org/listinfo/tb-planning</a>
</pre>
</blockquote>
<br>
</body>
</html>