Intent to de-support: traditional add-ons

[Magnus Melin]

Since version 57, Firefox only supports add-ons through the 
WebExtensions APIs. At the time, Thunderbird decided to continue 
supporting traditional add-ons, since we hadn't yet been able to develop 
replacing APIs for add-on developers to use.

Since then, Thunderbird has been developing WebExtensions APIs (aka 
MailExtensions), and the number of APIs available is continuously 
growing: https://thunderbird-webextensions.readthedocs.io/

Because the toolkit support for traditional add-ons has been largely 
removed, this has meant a lot of work for Thunderbird to keep things 
going for add-ons. For the server side it has also meant a lot of extra 
work (addons.thunderbird.net is a fork of addons.mozilla.org). Add-on 
developers haven't had an easy ride either: The number of changes to 
make an add-on compatible has been significant.

Going forwards we want to change this. Support for traditional add-ons 
is going to be dropped as soon as we're ready to do so internally. There 
are a few pieces of code that we need to convert over internally:

  * Lightning: to be integrated into the code base
  * Mozmill (used in our test infra): we're converting over to using
    mochitests instead

It's not yet clear exactly when we're ready to rip out the support for 
traditional add-ons from the code base, but it should be whitin the 
Thunderbird 72 time frame - so by end of 2019. The next major version of 
Thunderbird, version 78, will be out around June 2020. Up until then, 
code wise many things are going to change. For instance, what is left of 
XUL will be gradually going away, and documents will shifted to being 
XHTML with a less and less XUL flavor.

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.

As an author of a traditional add-on, what should you do? There are two 
routes: A) convert your add-on to a MailExtension. If the API you need 
doesn't exist yet, tell us about it 
<https://bugzilla.mozilla.org/enter_bug.cgi?product=Thunderbird&component=General>. 
B) convert your add-on to a Web Extension Experiment 
<https://thunderbird-webextensions.readthedocs.io/en/68/how-to/experiments.html>. 
Most add-ons should be able to be converted to an experiment with a 
reasonable effort. The recommended path is forward is to convert it to 
an a MailExtension though. That will make sure the add-on works without 
significant changes over many years. If you go with option B, you'll 
have to maintain a lot of more code yourself and breakages can and will 
be bad unless you keep up really close. MailExtension Experiments should 
be seen as such, experiments with the goal of getting the API they need 
into Thunderbird core. Please work with us on getting the needed pieces 
in as a supported API. Initially we'll be allowing experiments to be 
exposed to the general public, but over time (years) Thunderbird will 
gravitate towards not having the experiments available to the general 
public, the same way it works for Firefox.

  -Magnus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20191001/c03f404f/attachment.html>