Intent to de-support: traditional add-ons
mkmelin+mozilla at iki.fi
Tue Oct 15 10:19:58 UTC 2019
A few clarifications:
The changes are for the general public only going to come into effect in
the next ESR release, Thunderbird 78 in mid 2020. For developers, in
beta and nightly support will start to disappear from core once we're
ready do so, probably during 2019. Some notable things that will be
removed are the custom overlay loader (Overlays.jsm), and support for
add-ons requiring restart.
For add-on authors going forwards, there is of course also an option C
(depending on what the add-on does): work with us to integrate the
functionality into core. If the add-on is under the bug-fix category
this is certainly the way to go as no API for a bug-fix would be in
sight. In general we're happy to include functionality provided it's of
MailExtension Experiments is one way to go (and that's not deprecated),
but should not be seen as a long term solution. It may be a short term
solution though. It means you need to follow changes closely and things
will often break. Sometimes in ways that could be hard to solve. They
simply need to be understood to be seen as experiments, with no warranties.
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