=?iso-8859-1?Q?Re:_Proposal:_MailExtensions_API_to_allow_UI_overlays, _but_no_script_injection?=

opto@optosolar.com opto at optosolar.com
Mon Oct 14 19:15:57 UTC 2019


Reading this:

core changes, breakings;
>It will eventually be less major, but I'm guessing that will be a few years out.


it feels a bit silly to discuss now the deprecation of experiments. 

It is now three years or more that everything is unstable, breaks at LTS versions, has addons gone and that tb-planning has no idea where to go to (tb next generation and other ideas - five years ago?).

Weren't we encouraged to go to bootstrapped some time ago? Well, that is gone too, xul seems even more long living. Experiments are going before even started?

Currently, everybody knows that TB is unstable, anyway. I agree that has to improve in a major way.  But reading that comment above doesn't give any confidence that one could get there soon, so why kill off the addons and experiments now?

I don't believe TB will be as stable as Outlook, ever. Is that where the council wants to go to: better stable and few addons than somewhat unstable at LTS time and feature rich? A clarification would be helpful. The problem seems to be that without addons too few new features get into core - up to now, unless there will be a major change in manpower.

I am totally for stability, but at what costs?

I would be interested in the councils information on:

*TB users want a stable TB, even if without addons?
*TB users want open source with its addons, even if typical open source problems persist?

Is there any statistic on this?

Can there be a version with experiments, and another 'secure' without?

If the addon kills off the UI, so what?  Worst case, it can be cured by clean reinstallaton. Even Microsoft sometimes kills off my Win 10 UI, and there are many posts howto get rid of Microsoft updates. So having some instability at LTS time would be ok?

thanks,

Klaus



> 
> -----Ursprüngliche Nachricht-----
> Von: "Philipp Kewisch" <kewisch at thunderbird.net>
> Gesendet: 14.10.2019 09:14:22
> An: 
> Betreff: Re: Proposal: MailExtensions API to allow UI overlays, but no
> script injection
> 
> 

> On 14. Oct 2019, at 12:28 AM, Eyal Rozenberg
> <eyalroz at technion.ac.il> wrote:
> 
> 
> 
>>
> On 13/10/2019 22:48, Philipp Kewisch wrote:
>> If your strategy is
> that Thunderbird would accept that add-ons could break in any release
> and it would be up to the developer to stay up to date, I feel this
> would be a fair amount of work for developers to keep up with all the UI
> changes, as we have it now.
> 
> This was always the case until
> now - except that recently the changes are very frequent and more
> profound. Do you expect continuing profound changes?
> 
> If so,
> consider slowing down the release rate to allow us to keep up. And if
> the changes kind of settle down, then it will be tolerable again, like
> it was until v52.
I expect the changes to increase. Not only will
> Firefox continue to do large projects like get rid of xul, I expect
> Thunderbird to work on their own big projects that will affect the
> internals that Extensions are currently using.

It will eventually be
> less major, but I'm guessing that will be a few years out.

Doing less
> releases will just mean that there will be more for extension developers
> to adapt to.


> 
> 
>> You see in other threads here
> requests for documenting exactly what changed. If we change an id, some
> developers will expect us to tell them, bec. So it would be work for the
> Thunderbird team to communicate and document this.
> 
> Haven't
> seen requests for special documentation for every id change... more
> like, when it seems every other thing has changed, we might be grasping
> in all directions for something to hold on to.
I didn't say people were
> requesting each id change, but there is a general request for
> documentation on things that changed, which I think is a good
> request.

If we only have APIs to deprecate, we can much easier
> determine which add-ons need to update, and we can be more proactive and
> reach out to affected developers instead of relying that they read the
> hg log.

Philipp
> 
_______________________________________________
tb-planning mailing
> list
tb-planning at mozilla.org
https://mail.mozilla.org/listinfo/tb-planni
> g




More information about the tb-planning mailing list