Intent to de-support: traditional add-ons

Axel Grude axel.grude at gmail.com
Wed Oct 16 12:03:09 UTC 2019


Dear Magnus,

> or 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. 
I actually thought about this myself - if it means not losing the "privileged access" 
to the JavaScript / XPCOM layer it may mean a lot less work than constantly adapting 
an Add-on. There is only one problem - over the 10 years I am working4 on this project 
I have managed to turn it into a paid / self-employed thing, and with the amount of 
work ahead and to maintain the functionality, the only way to recoup would be to turn 
into a Thunderbird employee.

I am not sure if that's the correct way forward for me - would it possible to imagine 
a specialized / subcontractor position for an Add-ons developer so they can focus on 
just that specific work / functionality, rather than being deployed into stuff we may 
not be interested in?

The other argument against core is that only a small group of users may be interested 
in the functionality of these legacy extensions, and by rights /*they */should be the 
ones funding that. A "Thunderbird advanced" / freemium model might be a way out here. 
Just brain storming...

Axel

*Axel Grude <mailto:axel.grude at gmail.com>*
Music Production and Composition
Thunderbird Add-ons Developer (QuickFolders 
<https://addons.thunderbird.net/thunderbird/addon/quickfolders-tabbed-folders/>, 
quickFilters <https://addons.thunderbird.net/thunderbird/addon/quickfilters/>, 
QuickPasswords <https://addons.mozilla.org/firefox/addon/quickpasswords/>, Zombie Keys 
<https://addons.thunderbird.net/thunderbird/addon/zombie-keys/>, SmartTemplate⁴ 
<https://addons.thunderbird.net/thunderbird/addon/smarttemplate4/>)
Visit my YouTube Channel <https://www.youtube.com/c/thunderbirddaily> for email 
productivity tips Get Thunderbird!
> *Subject:*Re: Intent to de-support: traditional add-ons
> *From:*Magnus Melin <mkmelin+mozilla at iki.fi>
> *To:*<tb-planning at mozilla.org>
> *Sent: *Tuesday, 10/15/2019, 11:19 11:19 IST +0100 [Week 42]
>
> 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 general usefulness.
>
> 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.
>
>  -Magnus
>
> 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 
>> <https://bugzilla.mozilla.org/enter_bug.cgi?product=Thunderbird&component=Add-ons:%20Extensions%20API>. 
>> 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
>>
>>
>> _______________________________________________
>> tb-planning mailing list
>> tb-planning at mozilla.org
>> https://mail.mozilla.org/listinfo/tb-planning
>
> _______________________________________________
> tb-planning mailing list
> tb-planning at mozilla.org
> https://mail.mozilla.org/listinfo/tb-planning
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20191016/71c8f1ad/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: thunderbird_blog2.png
Type: image/png
Size: 846 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20191016/71c8f1ad/attachment.png>


More information about the tb-planning mailing list