Dropping legacy support: Moving forward

Philipp Kewisch kewisch at thunderbird.net
Sun Oct 13 11:31:23 UTC 2019


Hi Folks,

I think part of the problem is that everyone has different needs, and fulfilling some of them will be absolutely confusing to others.

The suggestion to use a richlistbox is great for people who are used to xul and want to make minimal changes to their add-on. It isn't great for people who use certain features of it or are having trouble with it. If the suggestion had been to use html, others would complain that they don't want to have to completely rewrite their code. As you see, nobody is happy in the end.

Regarding what to focus on and deprecating experiments, let's do one step at a time. Our goal is to get to a place where many use cases can be covered by the built in APIs, and that there is no need for experiments. This doesn't mean rhat every use case will be covered. To get there, we absolutely need experiments and extension developers writing then with the intent of making them part of core.

The reason we mention to not rely on experiments is that they shouldn't become the escape hatch. Developers shouldn't be writing their add-on in an experiment and packaging it in a WebExtension, they should be writing a Webextension and using experiments to fill the features that Thunderbird currently doesn't provide (but probably should). Otherwise, they risk yet another big rewrite down the line, along with an ask for documentation what changed in the platform in every release. This isn't great for the developer, and also takes time away from documenting WebExtensions and writing new apis.

Therefore, I don't think we should be having a discussion on when experiments will be removed. There will certainly be an announcement when this happens, and in the meanwhile experiments should be used to propose new core apis.

Personally, I feel we should be supporting paths on how legacy extensions can become WebExtensions, and not provide developers with documentation on how to update their legacy add-ons to use more legacy tech.

So, let's not discuss the death of experiments before they are even really getting started, but embrace them for what they are and use them wisely.

Philipp 

> On 10. Oct 2019, at 10:04 PM, "opto at optosolar.com" <opto at optosolar.com> wrote:
> 
> Mark:
> 1) 
>> This only took me an
>> hour or two to figure out.
> 
> I am sure that is valid for core TB people, you, Magnus, many others.
> 
> 
> It is not true for 'normal' addon authors (those which are not core TB).
> 
> This is what I want to bring over. For us, more support is needed.
> 
> 
> 2)
>> give
>> the add-on authors a route where they aren't going to have to do changes
>> every version
> 
> Currently, this is a misconception. We do have to change every version. When do you envision this state to start? As we are already discussing the death of webextension exp., that seems to be so far in the future as to be invisible.
> 
> 
> 3) I don't feel all this is heard from the viewpoint of addon authors, because over and over, it is repeated how relatively easy it is to do upgrading. 
> 
> There is a mixup of what effect the core changes have for core people, and what they cause for normal addon authors.
> 
> If you talk about addons, it is totally irrelevant how much time you, Magnus, Philipp, Jörg and many others would need. We know you are totally capable in coding TB.
> 
> But how about the others?
> 
> Many of the 'normal' addon authors have just ..  left, they are gone.
> So many, that it seems TB people are adopting/upgrading some addons so the users are not too angry or staying at 52/60.
> 
> How to get out of this loop:
> Primarily, information and guidance for conversion is needed. Currently, it is missing or outdated (e.g. the guidance to use xul richlistbox instead of listbox, which was ok a few months ago but now is a waste of time. And it is not working out of the box, so a time sink).
> 
> 
> 
> regards,
> 
> Klaus
> 
> _______________________________________________
> tb-planning mailing list
> tb-planning at mozilla.org
> https://mail.mozilla.org/listinfo/tb-planning



More information about the tb-planning mailing list