Intent to de-support: traditional add-ons
mkmelin+mozilla at iki.fi
Thu Oct 3 08:54:26 UTC 2019
If and when Manifest v3 is adapted by Mozilla, Thunderbird would also
adapt. But this is hardly about redeveloping everything once again. It's
a non backwards-compatible change, but AIUI, changes would generally not
be significant (YMMV).
On 03-10-2019 11:17, Emmanuel Sellier wrote:
> I fully understand, and agree, that it is necessary for TB to continue
> to evolve as closely as possible to Firefox's evolutions (for security
> reasons, in particular).
> However, I am somewhat concerned about the sequence of these
> developments. What will happen if Mozilla decides to fully adopt
> Google's Manifest V3 for Firefox extensions? Will it then be necessary
> to redevelop everything again?
> Translated with www.DeepL.com/Translator <http://www.DeepL.com/Translator>
> On Thu, Oct 3, 2019 at 10:05 AM Magnus Melin <mkmelin+mozilla at iki.fi
> <mailto:mkmelin%2Bmozilla at iki.fi>> wrote:
> On 03-10-2019 02:06, Eric Moore wrote:
> > I understand the motivation for wanting to drop all support for
> > add-ons in future releases but
> > (1) I don't understand why its so terrible to continue to store
> > distribute) legacy add-ons on Thunderbird.net for one more year
> > waiting for a fleshed out/more usable MailExtensions API to be
> > available, and more legacy add-ons to be rewritten as
> > Please elaborate on the reasoning why dropping legacy add-ons
> > in future versions and whats available in thunderbird.net
> <http://thunderbird.net> need to be
> > so tightly coupled.
> Anyone is of course (like now) free to host an add-ons collection on
> their site.
> For Thunderbird's side officially, it makes no sense for us to host
> add-ons that the application would not support. Maybe to clarify,
> addons.thunderbird.net <http://addons.thunderbird.net> will still
> host the traditional add-ons until
> Thunderbird 68 is EOL, so until sometime late 2020.
> > (2) Why can't the legacy add-ons on Thunderbird.net be made
> > somewhere else? Perhaps add a "legacy add-ons" entry to the add-ons
> > list box at Thunderbird.net that displays a single web page with
> > download links for all of the legacy extensions and complete themes
> > that support at least version 52. Users wouldn't be able to
> fetch them
> > from within Thunderbird, its not as convenient as if each had their
> > own add-on page, and some useful information is lost but at
> least all
> > of the legacy add-ons wouldn't just disappear.
> Well they can, it's just not Thunderbird's job to cater for that.
> Other than that, we don't want to encourage anyone to stay on an old
> version. You do realize there are *many* security fixes going into
> releases every few weeks? Just look at
> > (3) What is the target date for when the MailExtensions API (not
> > Experiments API) is expected to have the API most legacy add-ons
> > authors need, if things go well?
> I don't think that can be answered. Developers always "need" more
> they have. Expect additions to what we currently have, but full
> is not achievable through APIs. Old style add-ons could virtually do
> almost anything, and you can't provide an API to do anything.
> tb-planning mailing list
> tb-planning at mozilla.org <mailto:tb-planning at mozilla.org>
> tb-planning mailing list
> tb-planning at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tb-planning