<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Geoff,</p>
<p> a legacy extension (which needs a restart) can hold both
manifest types, the install.rdf and manifest.json. And it would
run with TB60.2.1 and TB63 --> TB65. That's how I'm doing the
"upgrade" of Reminderfox. And yes I'm faced with problems, but
they have nothing to do with the both manifest files .. I guess.<br>
If so it should be possible to build just one extension for
TB/current version upto TB65.</p>
<p>Guenter</p>
<p><br>
</p>
<div class="moz-cite-prefix">Am 29.10.18 um 09:37 schrieb Geoff
Lankow:<br>
</div>
<blockquote type="cite"
cite="mid:76a9de72-c407-8f8a-efd4-f961659a8f52@thunderbird.net">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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>
<div class="moz-signature">-- <br>
gNeandr <b>gmx</b></div>
</body>
</html>