Intent to de-support: traditional add-ons

Magnus Melin 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).

  -Magnus

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?
> https://blog.mozilla.org/addons/2019/09/03/mozillas-manifest-v3-faq/ 
> <https://blog.mozilla.org/addons/2019/09/03/mozillas-manifest-v3-faq/>
>
>
> 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
>     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
>     <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
>     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/
>     <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 <mailto:tb-planning at mozilla.org>
>     https://mail.mozilla.org/listinfo/tb-planning
>     <https://mail.mozilla.org/listinfo/tb-planning>
>
>
> _______________________________________________
> 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/98b0ae94/attachment-0001.html>


More information about the tb-planning mailing list