Mailcow-dockerized: How do I know when to update?

[MrSuttonmann]

I've been running mailcow for about a month now, and whilst the docs tell me _how_ to update, they don't tell me _when_.

What is the recommended update cycle, and is there any feed I can see version releases?

[PhoenixPeca]

Hi,

As for your question:

...is there any feed I can see version releases?

_For now, there isn't._ But we're expecting to have one: see #338

😄

[stevesbrain]

@lightswitchr Until then, I've simply been checking commits on master, and regularly pulling when they happen :)

[Braintelligence]

I've been also looking at problems people may have with latest commits before updating :p

[stevesbrain]

Haha, yes, I've been doing exactly the same :P

[andryyy]

Any ideas? We could use the mailcow version as image tag. And add an update script. Hm.

The update script can check against GH releases and overwrite the old files, pull the new images etc.

[stevesbrain]

If the GH releases version numbers matched mailcow versions and docker image tag numbers, I think it'd be pretty easy to determine which one we should be running (and guarantees compatibility that way) :)

[axd]

@andryyy You have plenty options one of them is to release a "stable" branch and make versions tags within that branch.

Something like:

|-master (old stable or legacy - merged from stable)
|-dev (unstable - very active - fix bugs)
|-pre-release (beta testing - merged from dev - fix minor bugs)
|-stable (ready for production - merged from pre-release)

After a real stable version make a release (tag) with the number of the version and so on.

The other way is just tagging:

|-master (main and dev branch, very active)

Tags:
|- v0.1 - First release
|- v0.2 - Adding feature
|- v.n.n - XXXXXXX
...

Those are some options that we have in Github. It depends on you and the needs of this community.

Regards.

[JOduMonT]

no saying is the best way
but this project : https://github.com/mitchellkrogza/nginx-ultimate-bad-bot-blocker
announce new version through mailling list and slack

[overheadhunter]

The other way is just tagging:

|-master (main and dev branch, very active)

Tags:
|- v0.1 - First release
|- v0.2 - Adding feature
|- v.n.n - XXXXXXX

I think the most straight-forward way is to have a dev and a master branch, which is supposed to only contain tested and production-ready code. Tags will allow you to post release notes right here on GitHub and can be read by (update) scripts.

I'd recommend Git Flow and SemVer.