Intent to de-support: traditional add-ons
emoore at fastmail.fm
Wed Oct 2 23:06:20 UTC 2019
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
(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.
(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?
From: Magnus Melin <mkmelin+mozilla at iki.fi>
> To: "Thunderbird planning (moderated)" <tb-planning at mozilla.org>
> Subject: Intent to de-support: traditional add-ons
> Dropping support for non-MailExtension add-ons is also needed for
> addons.thunderbird.net. Supporting old-style add-ons would require a
> significant investment in the back-end there, since the Django version
> of the back-end would reach EOL and have to go through a painful and
> expensive upgrade.
More information about the tb-planning