Automatically fixing addons for new Thunderbird versions
kewisch at thunderbird.net
Sat Aug 31 20:07:34 UTC 2019
So, there is a thing in ATN that will determine which add-ons are affected by an issue and inform those developers. You may remember the "your add-on is compatible with Firefox NN" emails.
Setting up these compatibility reports was fairly involved, but if someone wants to put in the effort then that would solve the notification case.
As for automatically rewriting add-ons, I don't think this is a good idea. I believe this discussion has come up before?
> On 30. Aug 2019, at 2:04 AM, Matt Harris <unicorn.consulting at gmail.com> wrote:
> How hard would it be to script in a tool that will sniff out and flag usage of deprecated interfaces?
> The documentation over the past months has mostly been "this is removed, use this instead". I do not see this changing a lot in the next release cycle and more XUL stuff disappears and more web API's become available to replace them. Having a script that could scan the code and identify the items in that list of chenges. Perhaps even anotate the code with developer links to comments would I guess make the process of updating abandoned add-ons by adoptive authors more likely. Not having any idea of the quantum of effort required is perhaps one of the barriers to others adopting the abandoned.
> But I am not an add-on author, so I will leave the discussion to those that have actual experience on the ground. But I would like to see the barriers to successfully getting an add-on off the ground to be significantly lowered. I look at VbScript and how simple it is to start to extend Microsoft applications with simple interface stuff and then I look to Mozilla and by extension Thunderbird. One is designed to encourage, the other expects a high level of technical skills and background. Dabblers not welcome Is the sign on the door.
>> On 30-Aug-19 12:30 AM, Axel Grude wrote:
>> And here I was getting my hopes up :)
>> Anyway it would be cool if there was a validation tool that just scans the code for keywords / used xpcom interface that we could use; using some diligence, a list to the said article would in many cases be enough for us Add-on devs to fix it ourselves.
>> I always think just having the validation scanner during Add-on upload as a separate tool /website would already be an immense help.
>> Axel Grude
>> Music Production and Composition
>> Thunderbird Add-ons Developer (QuickFolders, quickFilters, QuickPasswords, Zombie Keys, SmartTemplate⁴)
>> Visit my YouTube Channel for email productivity tips <thunderbird_blog2.png>
>>> Subject:Re: Automatically fixing addons for new Thunderbird versions (was: Re: Donations for the Provider for Google Calendar ...)
>>> From:Jörg Knobloch <jorgk at jorgk.com>
>>> To:<tb-planning at mozilla.org>
>>> Sent: Thursday, 8/29/2019, 15:44 15:44 GMT DT +0100 [Week 35]
>>>> On 29 Aug 2019 15:27, Ben Bucksch wrote:
>>>> If there are mechanical, scripted or very simple ride-alone changes that are applied to the whole code tree, then I think it would be good for the TB project to apply these to the addons as well.
>>> Sadly that's wishful thinking.
>>> A small fraction if those "bustage" fixes are s/xxx/yyy/. And even that we don't know that we're not hitting AAxxxBB.
>>> Most changes are much more involved. M-C is removing interfaces, turning sync calls into async calls.
>>> Take a look at https://developer.thunderbird.net/add-ons/updates/tb68 to see how unfeasible this suggestion is.
>>> tb-planning mailing list
>>> tb-planning at mozilla.org
>> tb-planning mailing list
>> tb-planning at mozilla.org
> “Against stupidity the gods themselves contend in vain.” ― Friedrich von Schiller, Die Jungfrau von Orleans
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tb-planning