Intent to de-support: traditional add-ons
mkmelin+mozilla at iki.fi
Tue Oct 1 17:26:46 UTC 2019
Correct bugzilla link to file bugs about needed APIs is
On 01-10-2019 16:02, Magnus Melin wrote:
> 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
> B) convert your add-on to a Web Extension Experiment
> 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
> tb-planning mailing list
> tb-planning at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tb-planning