Intent to de-support: traditional add-ons

Emmanuel Sellier emmanuel.sellier at verifrom.com
Thu Oct 3 08:17:12 UTC 2019


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?
https://blog.mozilla.org/addons/2019/09/03/mozillas-manifest-v3-faq/


Translated with www.DeepL.com/Translator

On Thu, Oct 3, 2019 at 10:05 AM Magnus Melin <mkmelin+mozilla at iki.fi> wrote:

> On 03-10-2019 02:06, Eric Moore wrote:
> > I understand the motivation for wanting to drop all support for legacy
> > add-ons in future releases but
> >
> > (1) I don't understand why its so terrible to continue to store (and
> > distribute) legacy add-ons on Thunderbird.net for one more year while
> > waiting for a fleshed out/more usable MailExtensions API to be
> > available, and more legacy add-ons to be rewritten as MailExtensions.
> > Please elaborate on the reasoning why dropping legacy add-ons support
> > in future versions and whats available in 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 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 available
> > 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
> https://www.mozilla.org/en-US/security/advisories/
>
> >
> > (3) What is the target date for when the MailExtensions API (not the
> > 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 than
> they have. Expect additions to what we currently have, but full parity
> is not achievable through APIs. Old style add-ons could virtually do
> almost anything, and you can't provide an API to do anything.
>
>   -Magnus
>
> _______________________________________________
> 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/20191003/16dfdd0e/attachment.html>


More information about the tb-planning mailing list