Maybe this is a silly question, but I haven’t found an answer: what should be the default branch for safe updates? I don’t want to break my production server by having some random failiures due to main
branch issues? Should I just follow the latest tag? I.e. v3.2.0
currently?
Hello and welcome @CGenie
I think the majority of people use the default tests-passed
branch, though some will use beta
or stable
. There’s a bit more info on the differences in Configure a supported tracking branch to get Discourse software updates
Why does Discourse always install "beta" versions by default? also explains the differences.
The answer, imho, is stable
as it receives minor bug fixes and security patches without changing most of the code significantly, usually resulting in greater compatibility as you upgrade through each patch.
The downside is that moving a minor version increase to, say 3.3.0
(in the future) might involve more significant changes you will have to deal with in “one go” instead of as a drip feed. This can especially impact customisations, e.g. bespoke plugins, that were built with the prior minor version in mind, but not tested on the new 3.3.x
series of beta releases.
On balance I’d suggest going stable
if you don’t mind missing out on the very latest features.
Though I think even on tests-passed
you’re in control of your own updates and can defer until you have time to check out any new features (possibly on a staging site if needed).
OK so another silly question: I use discourse_docker
to deploy the server. It seems discourse is set up with main
branch. How can I change that to tests-passed
?
Aah, ok, version
in containers/app.yml
is by default on tests-passed
. So I guess this is a sane config between stability and new features?
Word. And this is based on several years of experience in running a large-ish forum as self host. While beta or test-passed receives fixes and new features faster, the stable branch is predictable.
You know when major changes happen (version upgrades) and that in between versions the changes are minor. This way you can plan your own resources, prepare for some necessary testing effort, and potential breakage of your customizations (custom themes etc.).