[ajosh]

I've noticed that many of the linux repos are not up to date. If you're using those, you probably need to install it directly from the website to get the latest version and see the updates.

The major features that have come out lately that I've noticed are first-party calendar integration and first-party GPG support. There was a calendar integration but I always found it to be a bit funny and hard to get working all of the way. I never had problems with Enigmail, however.

Both features work much more solidly as an included part of Thunderbird. There are other, smaller features that have come in like having e-mail addresses in the To/CC/BCC lines be places into ovals to show them as a distinct, drag-able element.

The Thunderbird codebase is old and is full of a ton of features, transforming it in a way that is true to its past and moves towards a better future is going to take time but it is coming along. Sure, some of the major features were available as plug-ins but they're much more solid now that they're built-in.

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

[lrem]

First-party GPG support would be so nice to have some decades ago. By now seems everyone admitted defeat. Companies standardized on email as notification system for "you got a message in the actually secure medium". Humans standardized on using some inherently safe (but usually not open) communicator. Who is there still wanting secure email?

[ajosh]

This question (and the one above right now) are good points. GPG isn't really a killer feature right now. I likewise haven't needed secure e-mail in a while. I just happened to notice it when it migrated stuff over. I stopped using my Yubikey with gpg a while back.

All of that said - I'm replying to this message and not the other because there is one use for secure e-mail that may make a difference: DeltaChat. Deltachat uses autocrypt which includes your public key in headers. With autocrypt in place, Thunderbird can still read DeltaChat messages.

I'm not sure if DeltaChat will ever take off in large numbers but it seems like a decent option for secure chat/IM.

[lrem]

First time I hear of DeltaChat. Does it use email as the actual transport? Sounds prone to stupid latency. What's the benefit over Matrix?

[brnt]

It does, and the benefit is that anyone with an email address can already be approached via Deltachat, because all it does is send and receive email through the Autocrypt protocol, which gracefully degrades with clients that don't support it.

[akerl_]

Gracefully degrading for clients that don’t support it is an un-goal of encrypted messaging.

[ekianjo]

You cannot read encrypted messages if you do not have gpg support. Not sure what your comment is about.

[gsich]

Latency is not that bad usually.

[submeta]

> Companies standardized on email as notification system for "you got a message in the actually secure medium".

This is so ridiculous. I have to log in to a dozen different sites to download documents. And those sites are 2FA secured, so I have no means to automate. Of course these companies never heared of (REST) APIs. - This is such a step backwards.

[lrem]

Frankly, I prefer my bank and insurance to have minimal access surface.

[411111111111111]

But why don't they support just sending them to your email, gpg encrypted if sensitive? They'd still be secure and significantly easier to archive

I know it's for liability reasons, but annoying nontheless

[lrem]

That's an extra thing they could get wrong. Seeing how some banks cannot deal with copy-pasting my legal name correctly, I prefer to not give them anything else out of the ordinary.

[bsder]

> By now seems everyone admitted defeat.

Well, since everybody is using Gmail or Office365 anyway, encrypted email is kind of pointless, no?

[gsich]

GPG works with all mail providers.

[ekianjo]

If you encrypt something within gmail only you and your recipient can read it. Not sure what you mean ?

[iudqnolq]

Their point is so can gmail, and thus the govt through various channels.

[gsich]

No? All they see is yhe encrypted mail.

[ryukafalz]

I still haven't been able to get the new GPG integration working with my Yubikey, that whole path seems not super well-supported yet. And Enigmail doesn't run on more recent versions of Thunderbird.

I haven't had to work with encrypted email for a little bit, but I think the next time I do it'll push me to another email client if I still haven't gotten this working.

[ylk]

You'll have to do some additional configuration: https://wiki.mozilla.org/Thunderbird:OpenPGP:Smartcards

[ryukafalz]

Right, even with that I haven't gotten it working. I'm sure I'm doing something wrong, but the failure modes don't make it particularly clear what the problem is.

[AdmiralAsshat]

I thought I had installed the flatpak for Thunderbird some time ago, but apparently I was wrong; I'm still pulling the RPMs down from Fedora repos.

Those seem pretty close to upstream, however. I got an update for it just last week.