Best practice to update chatmail relay [also: releases vs. main branch]

Chatmail Relays
,
1

I wonder why there’s no admin instruction on how to upgrade a chatmail relay safely. I found this post but from a DevOps perspective this is far from ideal. Let me explain why:

The last official release (1.9.0) is from December 2025. But following the official instructions you always clone the “bleeding edge” main branch from GitHub and never any of the releases. So what are the releases for then?

I see that there is constant development in the chatmail repository, which is really great. But I don’t think deploying a “work in progress” repository to my production server is a good idea. In this case the recommendation “Make sure you review the changelog for any changes that need action from you.” (from the linked post) would mean I have to check all commit messages and changes and “predict” if it’s a good idea to to a redeployment or not.

Are there any thoughts on whats best practice here?

I ask especially because I repeatedly experienced some kind of “edit race condition bug” where the edit of a message on one of my devices was only synced to e.g. the phone but not to another machine which was offline during the edit. So my idea was to update the chatmailrelay first before opening a bug report.

3 Likes
2

It would be really nice to have Debian stable releases of the package. Debian stable servers are popular because they get excellent security support and are extremely low-maintenance. This would fit really well with the design goals of the software. The disadvantage of Debian stable is that new features are only added every two years or so, but for a standards-based mailserver this should not be a big problem.

3

I’m not a developer but as the author of the linked post and relay operator, what I meant was not to check the git commit history, but rather the file seen at relay/CHANGELOG.md at main · chatmail/relay · GitHub

There is nothing wrong if you update only when a new release is out.