Concerns on thunderbird snap update policies

I am a long-time user of the Thunderbird snap and overall happy with the update process. However, the recent issues with the v102.7.0 update that broke Microsoft OAuth 365 authentication have given me some concern whether there is any build management happening on the Canonical end or whether it is just publishing automated builds without much oversight.

The first issue I see is that while Mozilla halted the roll-out of v102.7.0, the snap build was not reverted to the previous working version and current/new thunderbird snap users would get the known-broken build by default. For existing users it was possible to ‘snap revert’ to the previous version, but this would not be available to new snap installs.

Related to this issue, the time between publishing builds to the latest/candidate channel and promoting to the stable channel seems to be very short (<1 day). This also meant there was not enough time for the issue to be flagged and the build promotion to be halted. This could be addressed by increasing the time to stable promotion but it does not address the issue that there is apparently little oversight to prevent known issues from ending up in the stable channel, or backing out of these builds.

Finally, when new major releases are made available the Mozilla policy is often to hold automatic updates of clients until at least the .1 version. For example, build 102 was not considered stable until it reached 102.1. However, this is also not taken into consideration for the thunderbird snap build, which had the 102.0.0 build pushed to the stable channel when this was against the release policy. Again, this reinforces the idea that builds are published automatically without oversight of release notes or serious known bug reports.

As a long time user of snaps because of the extra layer of sandboxing they afford (especiall to networked applications), it would be wonderful if the Thunderbird release policies can be improved. Some suggestions for improvements are:

  • Increase time between releases from the candidate to stable channel and improve oversight to ensure that releases with known major bugs that halted rollout (published in e.g. the release notes and Thunderbird blog) are not promoted to stable.

  • Ensure that new major releases are not automatically promoted to stable, but instead follow mozilla policies to not push automatic updates until a later (approved) point release. For this purpose it may be good to have an additional ‘edge’ channel for new major releases.

  • Finally, there should be a possibility on the snap store side to revert to an earlier build if there are known major bugs with the current release in the stable channel that halted a Mozilla update roll-out.

while i’m not a thunderbird user (nor affiliated with the snap maintenance for it), the fixed TB version v102.7.1 is available in the stable channel since a week now and was to my knowledge immediately pushed out when available …

Unfortunately the initial fix did not address the issue (see and for more details). The final fix was released last night and is now in the candidate channel.

The new build2 revision which should correctly includes the fix is in stable now

Perhaps a more concise summary of my initial post would be that Thunderbird builds that are not offered as as automatic updates to users by Mozilla should also not be released into the stable snap release channel. That would go a long way in avoiding issues beween major version updates and with releases whose roll-out was halted.

Thanks for the feedback. The promotion isn’t automatic at the moment but our testing is somewhat limited (doesn’t include office 365 for example).

We pondered reverting to the previous revision but by the time that was considered there was a 102.7.1 being rolled out upstream which was meant to fix the specific regression so we decided to just go that one through instead.

We should follow upstream on when major updates are being rolled out though. Do you know if there a place where we can query the information from a programmatic way? (trying to guess the information from blog posts and release notes isn’t ideal). The snap store also allows progressive rollout to users which we should use

on a side note, you can always do snap revert thunderbird to get your local install back to a working version in case something broken was rolled out, this is a core feature of snap packages…

I’m afraid I don’t know how to track programmatically what builds are offered as automatic updates. Perhaps someone from the Mozilla Thunderbird team could provide guidance here?

The snap revert command indeed worked to restore the previous working version, but this option would not be available for new installations. It also seems that when a new version is promoted, the previous version is no longer available in the stable channel. That means that trying to force-install an earlier version by specifying a specific version number doesn’t work.

As an aside, when I ran snap revert thunderbird to go back from version v102.7.0 to v102.6.1 this resulted in pixbuf errors that caused the window controls and attachment icons to be greyed out. I was able to resolve this by deleting the ‘.config’ and ‘.local’ folders in the ~/snap/thunderbird/current’ folder. Perhaps this was due to an issue with the icon cache?

that sounds like a bug to me … (bits that live in ~/snap/thunderbird/current but perhaps should be in ~/snap/thunderbird/common or vice versa (would need more research))