Release branches are treated as pre-releases

[yecarri]

Describe the bug
Given there is a GIT repository with this structure:

master
      \
       develop--------------------
          \                  /    \
            feature/feature1        release/1.2024.1

when I checkout release/1.2024.1
and I run GitVersion
then SemVer should be 1.2024.1

Expected Behavior

SemVer should be 1.2024.1

Actual Behavior

SemVer is 1.2024.1-beta.1

Steps to Reproduce

As described above

Context

The result is the same even if I use a GitVersion.yml file with a release branch and set the is-release-branch to true:

    release:
        is-release-branch: true

Your Environment

• Version Used: release 6 beta 5
• Operating System and version: Windows 10

[arturcic]

@HHobeck can you check this one?

[HHobeck]

Hi there.

Am I right that on the release branch the label configuration is set to the value beta? Your version will always be a pre-release version until you are marking the commit with a dedicated tag. In your case because you are on the release branch it will be yield with a beta pre-release. Even though if you specify an empty label you will get a pre-release version with value 1.2024.1-1.

Regards

Hardy

[yecarri]

Hi @HHobeck

I can't see the logic of a pre-release commit in a release branch. In our pipeline, whatever is merged into a release branch is a release, not a pre-release. We have used GitVersion for the last 3 or 4 years and it worked as I explained. This is a significative change in the behavior.

[asbjornu]

@yecarri, according to the Gitflow workflow, release branches are not indented to be stable for each and every commit to the release branch. release branches are branches whose purpose is to stabilize the build. Once the release branch is considered stable and ready, it is merged into main.

The merge-commit of the release branch into main is tagged and then that tagged merge-commit is what should produce a stable, finalized, deployable artifact versioned without a prerelease label.

Once develop has acquired enough features for a release (or a predetermined release date is approaching), you fork a release branch off of develop. Creating this branch starts the next release cycle, so no new features can be added after this point—only bug fixes, documentation generation, and other release-oriented tasks should go in this branch. Once it's ready to ship, the release branch gets merged into main and tagged with a version number. In addition, it should be merged back into develop, which may have progressed since the release was initiated.

Using a dedicated branch to prepare releases makes it possible for one team to polish the current release while another team continues working on features for the next release. It also creates well-defined phases of development (e.g., it's easy to say, “This week we're preparing for version 4.0,” and to actually see it in the structure of the repository).

[yecarri]

We are using a variant of GitFlow. We don't deploy from master. Instead, we deploy from different release branches. We may have different releases deployed to different implementations, so we need to keep the release branches alive and we branch from release branches, not from develop, when we need to fix issues. All we need is the possibility to generate a semver without pre-release tag. Our pipeline uses that output to automatically tag the commit.

[asbjornu]

Sounds like you're using release branches like support branches. I would advice you to stop calling them release and rename them to support, or at least configure them as such in GitVersion.

[HHobeck]

We have changed the behavior of ContinuesDeployment and give this mode a new meaning. This feature can be used in the upcoming version 6.0.0-beta.6 of gitversion which would be exactly what you are asking for. What I'm surprised with is that you are saying it's bug. It's definitely a new feature which was not support before.

Actually we are doing a refactoring on the versioning mode and redefined the meaning. At this moment (in the 6.0.0-beta.4 version of gitversion) we are not finished with the transformation and that is the reason why only the 5.x definition is documented (please take a look here). For this discussion I want to focus on the target design which is agreed here.

• ManualDeployment, (previously ContinuousDelivery)
• ContinuousDelivery, (previously ContinuousDeployment)
• ContinuousDeployment (New)
• Mainline (will be removed)

At the end I want to make clear it doesn't matter for the algorithm what mode you are using. It is just a representation of the calculated result which has at least the following parts {Major}, {Minor}, {Patch}, {CommitSinceLastTag}, {PreReleaseNumber} and {PreReleaseLabel}. If you take for instance a next version increment of {Major} = 1, {Minor} = 2, {Patch} = 3, {PreReleaseNumber} = 4, {PreReleaseLabel} = beta and {CommitSinceLastTag} = 5 then you get:

• for mode ManualDeployment 1.2.3-beta.4+5
• for mode ContinuesDelivery 1.2.3-beta.8 ({PreReleaseNumber} +{CommitSinceLastTag} -1) and
• for mode ContinuesDeployment 1.2.3 (the other parts will be not used for the semantic version)

(see #3492 (reply in thread))