How should I handle beta releases in the default gitversion configuration

[bitbonk]

I have a pretty simple and default giversion setup. gitversion.yml only contains the following line

next-version: 1.0

So I have the standard branches "suggested" by gitversion.

• develop the default (protected) branch
• main the (protected) branch where the releases happen
• feature/foo a feature branch that will always be merged into develop
• release/1.0.0 the branch where a 1.0.0 release is prepared (probably protected too, if it lives longer)

In this "default" gitversion scenario, what would be the preferred way to handle 1.0.0-beta releases? I see two options:

1. Create beta releases off of the release/1.0.0 branch. All work merged from a feature branch into develop targeted for the final release of 1.0.0 must be merged from develop into release/1.0.0. Only when the final release is about to happen, merge release/1.0.0 into main and then to the final relase of 1.0.0 off of main with a 1.0.0 tag.
2. Create a branch named release/1.0.0-beta1 which only exists to prepare the release/1.0.0-beta1. It will be merged into main when 1.0.0-beta1 is ready for release. And the 1.0.0-beta1 release will be done off of main with a 1.0.0-beta1 tag.

What might be strange with approach 1 is, that as soon as bran release/1.0.0 exists, it seems all builds of develop will get the version number 1.1.0-alphaX. Even though 1.0.0 was not yet released and even though it is not clear whether the subsequent changes made on develop really are changes that need a minor increment or whether the will ever be a 1.1.0 release.

What might be strange with approach 2 is that main contains beta releases.

I suppose that gitversion had some strategies in mind when they chose the defaults (e.g. alpha tag for the develop branch, beta tag for release branch, continuous deployment for the develop branch etc.). How would a good release strategy for beta releases look like in the default gitversion configuration?

[Justegard]

Reading the gitflow examples from the gitversion docs beta versions are tagged and built in the same release branch as option 1 states, which seems to create much less overhead than option 2.

[bitbonk]

One short follow-up question: Should the release\1.0.0 branch be a protected branch on the CI server? It would basically prevent that this branch can be rebased on top of develop. Is that a good practice?

[Justegard]

I think it's a good practice to have protection on release branches, so you won't lose control over what you're actually releasing.