| > Alternatively, and not so good, the other answer is to maintain shims or back-ported APIs for some duration If I understand correctly, this is what they're actually doing. From https://developer.thunderbird.net/add-ons/updating/tb78: > Knowing that following the proper migration strategy is not easy, we created two wrapper APIs which do not require all of these changes. Using these APIs, you can quickly get your add-on running in Thunderbird 78 again, but you will not get the benefits of a MailExtension. The idea behind this is to make add-ons compatible with the current ESR as quickly and easily as possible, so users can continue to work with their beloved add-ons. Per se, this would be a sensible move. However, in the bigger picture, the plan starts to show its pointy-hairedness: > While the Thunderbird team plans to add more APIs with upcoming releases, the current set of APIs will not be sufficient to port most add-ons. To work around this limitation, add-ons can introduce their own, additional APIs as so-called Experiments [...] [which] are expected to require updates for each new version of Thunderbird. In other words, the TB team, for unspecified reasons (it's not clear if they were really forced to move to MailExtensions), has broken compatibility with the previous versions of the addons, and provided half-baked APIs which are expected to break again in the future. Other mind-numbing pointy-hairedness: > [...] If you follow this strategy, you will end up with a future-proof MailExtension that will require substantially less maintenance work for future versions of Thunderbird. They're saying in a single sentence that updated addons won't require changes in the future (being "future-proof") _and_ that they will require them. === All in all, I have the strong suspicion that Thunderbird is very incompetently developed/maintained, but I'd be very happy to be proven wrong (with technical arguments). |