[pizza234]

> I've noticed that many of the linux repos are not up to date

This is very tricky.

Thunderbird keeps breaking addons compatibility (as an end user, I don't care if this is justified or not), by supporting main versions for short times (v68 was released less than two years ago).

An O/S like LTS Ubuntu, which has a 4+ years support cycles, is systematically forced to break TB compatibility during each cycle, which is contrary to the O/S versioning guidelines (which typically freeze the program versions, with the exception of security upgrades, e.g. web browsers).

As a side effect, addons, which give TB a significant value (I'd argue that they give its only value - even Google Calendar is not natively supported) slowly disappear.

Thunderbird is essentially systematically and forcefully breaking versioning and compatibility. I believe something's broken in the team/company.

[coryrc]

Given the resources available, I don't think they can make the product better and maintain compatibility for long. Given the previous decade+ of minimal enhancement to the point where it's now just the tiniest fraction of email users, standing still is a guaranteed death sentence.

[lstamour]

I figure the easy (though actually hard) answer is to try to collect commonly used add-ons in one central place and update those there, the same way that TypeScript can always keep moving as a language while centrally publishing new versions of types with backwards compatibility to older language APIs.

Alternatively, and not so good, the other answer is to maintain shims or back-ported APIs for some duration as downloadable add-ons that extensions could use. You could add existing extensions to a giant test-suite that ensures common extensions don't break.

You could combine all these approaches, of course. Personally, I'd push to have common community add-ons maintained centrally though, such that if they change an API and it's a relatively easy fix, project maintainers could automate a "code-mod" or fix to rename and use the new API, or shim support for the old API? It's not easy, exactly, it requires taking ownership of a community to such an extent that you can ship API changes as useful codemods to help automate community porting efforts.

That said, I've often found that even if plugin APIs don't change, requirements to list compatible API versions in plugin manifests can make it hard to use new plugins until app authors can get around to updating the manifest to a new version and ensure compatibility for their extension. It might be interesting if app or extension stores could run tests to confirm if a plugin is compatible or not and if not, maybe suggestions could be made to point projects to new APIs and porting guides, if not outright automated PRs for fixes?

[pizza234]

> 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).

[pizza234]

Well, I use Thunderbird in the following way:

- Basic IMAP/POP3 client

- with GPG integration

- without global indexing (I use simple searches)

and in the entire TB history, I can't remember anything that significantly changed the usage of the above.

What I remember though, is that, even with lack of resources, at some point they added a chat client!!!

[silon42]

IMO, distros should start packaging good addons anyway.