Intent to de-support: traditional add-ons

Eric Moore emoore at
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 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 need to be so 
tightly coupled.

(2) Why can't the legacy add-ons on be made available 
somewhere else? Perhaps add a "legacy add-ons" entry to the add-ons list 
box at 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>
 > To: "Thunderbird planning (moderated)" <tb-planning at>
 > Subject: Intent to de-support: traditional add-ons
 > Dropping support for non-MailExtension add-ons is also needed for
 > 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 mailing list