How I've done it: Just tag the commit that is used to build a release. If you need to add a fix to an older release, create a branch from the tag. Do the changes trunk based on this branch, then tag and release. If needed just repeat it.
I'm convinced that complex branching strategies never magically solve any issues. They just confuse many people until every successful release feels like dark magic.
I don't like long lived branches. For me a branch is work in progress. Work should be finished, once finished the branch should be deleted. If you start work again, create a new branch.
But sure, if supporting an older release is some kind of ongoing trunk-based process this is also a viable solution.
Comments
How I've done it: Just tag the commit that is used to build a release. If you need to add a fix to an older release, create a branch from the tag. Do the changes trunk based on this branch, then tag and release. If needed just repeat it.
I'm convinced that complex branching strategies never magically solve any issues. They just confuse many people until every successful release feels like dark magic.
Why not keep a permanent, separate branch for each version that is still maintained? And do trunk on each version branch.
I don't like long lived branches. For me a branch is work in progress. Work should be finished, once finished the branch should be deleted. If you start work again, create a new branch.
But sure, if supporting an older release is some kind of ongoing trunk-based process this is also a viable solution.