Oh dear, Thunderbird’s 115 to 128 upgrade is rumored to be as catastrophic as some of their past upgrades. Every now and then the UX designer types decide they have no purpose in life except to screw up everyone else’s day and teach them why they, kids who think tiktok is the best app ever, need to change every grown-up’s email interface to match their hipsterisms.
A slightly editedrant I posted about this for a previous widely hated, horribly disruptive, mostly useless “update” that was forced on the user community is still as relevant as it ever was:
A core philosophical failure that blights the development process and engenders much frustration and gnashing of teeth among the loyal, long term users is the assumption that what the developers believe is progress is what the users need, it ain’t Brondo.
All of us who are (or were) users of TB (or any program) became so because it did something we needed it to do. Changing that function, even cosmetically, is going to hurt some users, even if there are valid and rational arguments why it is an improvement. In an environment that embraces the concept of radical consent in so many ways, stuffing an upgrade down the throat of an existing user without even a “hey, you want this?” is inconsistent with modern social norms of enlightened behavior.
It is possible, of course, to reject upgrades, but it is a huge hassle and means blocking all updates, including security fixes, just to avoid the addonpocolypse ones like 68, 78 and 115 that utterly destroy functionality for months, even years as the still (amazingly) dedicated developer community finds ways around problematic API changes (even accepting the changes are meaningful security changes or driven by FF codebase migrations that would be unreasonable to expect to preserve without doing a waterfox kind of fork). The default is to auto-update, as we do for most programs and most of the time without the radical trauma of some TB updates.
Not every update breaks add-ons but some do (incorrectly). Add-ons generally do not self-update on unsupported versions (correctly). TB should consider add-ons first class code citizens, not trivially disposable cosmetics. They are operational modifications to a vehicle not JC Witney double stick racer mods. Users had a legitimate need to modify the base operation of the program, sought out and applied a solution and it isn’t acceptable to negate that effort without warning. Every TB update should do what plugins do: check compatibility and refuse to update until the user manually disables any incompatible plugins rather than simply disabling them for the user and saying “check it out! new! Sleek!” (sorry, nothing works anymore, but looks nice, huh?). All reasonable efforts should be made to preserve compatibility indefinitely, but that’s obviously not always possible to keep the code base manageable and secure, and it is fine to inform users that there are important security reasons that require breaking plugins, but never, ever to do so without informed, affirmative consent.
As for UI/UX changes, I’d argue that the philosophy should be no change, not even trivial cosmetic ones, are permitted on an existing install. Ever. If you started with TB 0.1 your 115 interface should look exactly like this:
Unless you explicitly gave informed, affirmative consent to UI/UX changes.
Save your mail
Well, they haven’t followed my advice, but there are workarounds to mitigate the harm of having the devs jam yet another unwanted “upgrade” into your day: don’t upgrade! You don’t have to and while it may make sense after some time, it almost never makes sense to take one of these, what used to be VNUM changes updates early. Ah, yet another dumb change, the loss of PNUM: so many projects adopted the utterly idiotic flat numbering system that doesn’t differentiate between minor bug fixes and major changes in any useful way. Who thought that was a good idea and what can we do to ensure they never work in technology again? Why is my install jumping from 115 to 128? The level of dysfunction is, certainly, frustrating. I guess it is more sensible than 3.1, XP, 95, 98, Vista, 10, 11.
Most automatic updates are either done by your operating system or initiated by the app itself. As I’m on Linux, the examples will be from my environment, but there are plenty of windows guides around.
Block Application-Driven Updates
To stop the app from self-destructing with some stupid upgrade, you need to create a special file in a special, super secret location and to make it even more fun, the location depends on what operating system you’re using and how you installed the application. if you have restored your menu bar, the one they deleted some time ago, it’s easy, otherwise it’ll be a “hamburger icon” or some other dumb variation:
Help menu -> Troubleshooting Information
Application Binary /usr/lib/thunderbird/thunderbird means the application binary is in the directory /usr/lib/thunderbird/ inside of which (navigating by your file browser or command prompt) you should find a distribution directory.
Inside the distribution directory, create a file named policies.json, this is a protected directory so the linux command will be something like sudo nano policies.json. The text of the file should read:
{
"policies": {
"DisableAppUpdate": true,
"DisableFeedbackCommands": true,
"DisableSystemAddonUpdate": true,
"DisableTelemetry": true,
"ExtensionUpdate": false
}
}
Disabling extension updates is debatable but major API fixes mean sometimes an extension will update to the new version and stop working on existing. Extension developers are usually pretty good about avoiding that (unlike the core devs) so consider that particular line debatable.
Block OS-Driven Updates
This is a purely for Ubuntu derivatives that support Synaptic or similar. Launch Synaptic, find the thunderbird entry and selected Package -> Lock Version.
These fixes should keep you safe from massive disruption. It can take months or more, for essential Add Ons to get updated and functional or for someone to develop a compatible alternative. The thunderbird dev team just doesn’t care about either Add On developers or users but, unfortunately, it is the only usable email tool left on the desktop that supports sadly essential HTML mail.
Claws… I get it, html mail is a pox on humanity, but please reconsider:
Claws Mail will not let you write and send HTML emails or other kind of annoyances, hence it may not be the software you need in some business environments.
Being Right isn’t always write.
Leave a Reply
You must be logged in to post a comment.