How to handle release candidates in git-flow

user_5325012 0
Viewed 168

We're working by the git-flow workflow. Typically we release some release candidates (RC, v1.0.0-rc.0) before we ship the final release (v1.0.0).

To do so, we have a release branch (release/1.0.0). The release candidates are just tags within that branch. The release branch is not merged into main until we have a final release.

Today we discussed whether we should open a release branch for every release candidate (e.g. `release/1.0.0-rc.0) and merge these into main whenever the candidate is released.

Any opinions on this one?

release-candidate git-flow workflow release-management
1 Answers

Generally, if each of the previous release candidates are reachable by the newest one, then they could be on the same branch, and therefore there isn't any benefit to having separate branches for each.

If you wish to make a new release candidate that does not start from the current release candidate (e.g. perhaps you need to back up a few commits, or even start over), then that would be a good time to consider creating a new branch.

I assume once you merge into main you can delete all of the release branches, whether they were fully merged into main or not. Since you still have the old release versions tagged that you didn't use, you could always go back to them if you wish, even without the branches.

user_1845460
Related