[alfiedotwtf]

The thing missing with a lot of these branch management posts is release management… because it’s lovely to live in an ideal happy-path world, but what happens when main is tagged for release, only some customers update, main moves of with multiple breaking changes, and only then do some customers require fixes to their releases (who could all be on different i.e even older tags)?

Do you take their tagged release, fix it there, and then send them that branch release with the fix, or do you send them a fix on current main - you know, the main that is now a million releases ahead with multiple breaking changes? And what about all the intermediate release tags? Do you fix each one there too if they have the problem, or do you only update when customers on those releases start having that issue too?

And if you fix to their old tagged release which is incompatible from main, does this mean you have to do this fix twice i.e on their tagged release and also fix it for main? But what if this fix affects other people who are all on different branches too? Now… times this by 20 different customers all running different hardware and different branches with different problems :(

Maybe my comments are off topic, and don’t get me wrong - I prefer “trunk is releasable” motto, but I think maybe as an industry we should all come up with an Acid Test (like the only CSS Acid Tests) so we can through all these branching strategies into the ring

[eddd-ddde]

I've commented about this before.

The answer is development branches are forbidden but releases still use a kind of branching approach.

When you make a release you use commit A from main, then development continues, commit B adds a feature, and maybe commit C fixes a serious bug.

You don't want to make a new release at C because it includes new non tested features, instead you cherry-pick fixes to your release, test the new release candidates, and release that when ready.

Development still happens in main however.

Another big tool to minimise these problems is to separate the concept of feature release from the concept of binary release. You don't have to make a true deployment to release new features or roll them back, just use a toggle switch.

[Longwelwind]

Trunk-based development fits nicely when you have a single deployment product like a SaaS and you don't need to maintain old versions of your software. You only have one prod environment.

If you build a software that you distribute so people can deploy it themselves (a library, a self-hostable solution, ...), then you most likely semantic versioning. In that case, the best model is to use what semantic release offers.

[F-W-M]

If you need to support multiple versions at the same time, you need to extend TBD in some way.

We just cherry-picked stuff back to release branches, if we needed a fix.

[csb6]

Yeah, I work on avionics software where we sometimes need to support old releases with fixes for many years, and this is basically how we do it. Essentially maintaining multiple trunks and only backporting changes needed by customers using the old releases (there is a high bar so it has to be something like a security fix or an important bug fix)

[Zardoz84]

we have a "release" branch and a "develop" branch. The release is trunked on the last released version and (in theory) only gets fixes. If we need to fix a more older version, we create a temporary branch on that version to fix it, and we cherry pick the fixes (or merge to) to release branch and then to develop branch.

The triple mortal loop, comes that we have two versions of the product. One with the old no responsive frontend and other with a modern responsive frontend. And we need to release and develop the two versions for sometime, before the direction decides to kill the old no responsive version. So we end with 4 branches: release, release_rwd, develop and develop_rwd. If we fix something in release, we need to do a diamond merge : release to release_rwd, release to develop, release_rwd to develop_rwd and develop to develop_rwd