Main/release branch always adds a prerelease tag.

[toadicusrex]

Prerequisites

• I have written a descriptive issue title
• I have searched issues to ensure it has not already been reported

GitVersion package

GitVersion.Tool

GitVersion version

6.0.2

Operating system

Linux, Windows

What are you seeing?

I have tried a crazy number of combinations, but my main branch which should never have prerelease tags is adding prerelease tags every time I commit, unless I also manually commit a version tag (i.e. "v3.5.0"), which it then uses to create a tag like "3.5.0" on the same commit. I grant that this might have something to do with my setup but it behaves the same in both Azure Devops as well as GitHub Actions, and on my own development machine. This worked with version 5.x of GitVersion, but now I've upgraded and I'm hoping to find a quick solution so that my main branch pipeline runs produce release tags without manual intervention (manually adding a release tag). This is related to #4175 I think.

What is expected?

Release branches don't produce gitversion values with prerelease tags. All other branches should build tags with prerelease tags, and they should version based only on version tags and/or commit messages in their direct ancestry (i.e. should not pull highest build version from main unless that version tag is in the same direct ancestry).

Note that I want ContinuousDelivery, not ContinuousDeployment. I want a new version on every commit to master/main, I just want it to not have prerelease tags.

I'm going to try to do a PR if I can figure this out, but I'm hoping I've just made a mistake and I misconfigured it.

Steps to Reproduce

I might be flailing a bit, but here's my config:

assembly-versioning-scheme: MajorMinorPatchTag
assembly-file-versioning-scheme: MajorMinorPatchTag
tag-prefix: '[vV]?'
version-in-branch-pattern: (?<version>[vV]?\d+(\.\d+)?(\.\d+)?).*
major-version-bump-message: '\+semver:\s?(breaking|major)'
minor-version-bump-message: '\+semver:\s?(feature|minor)'
patch-version-bump-message: '\+semver:\s?(fix|patch)'
no-bump-message: '\+semver:\s?(none|skip)'
tag-pre-release-weight: 60000
commit-date-format: yyyy-MM-dd
merge-message-formats: {}
update-build-number: true
semantic-version-format: Loose
strategies:
- Fallback
- MergeMessage
- TrackReleaseBranches
- VersionInBranchName
- Mainline
branches:
    main:
        mode: ContinuousDelivery
        label: ''
        increment: Patch    
        prevent-increment:
                of-merged-branch: false
        track-merge-target: false
        track-merge-message: false
        regex: ^master$|^main$
        source-branches: []
        is-source-branch-for: []
        tracks-release-branches: false
        is-release-branch: false
        is-main-branch: true
    release:
            mode: ContinuousDelivery
        label: '{BranchName}'
        increment: none
        prevent-increment:
            when-current-commit-tagged: false
        track-merge-message: false
        tracks-release-branches: false
        track-merge-target: false
        regex: (?<BranchName>.+)
        source-branches: []
        is-source-branch-for: []
        tracks-release-branches: false
        is-release-branch: false
        is-main-branch: false
ignore:
    sha: []
mode: ContinuousDelivery
label: '{BranchName}'
increment: Inherit
prevent-increment:
    of-merged-branch: false
    when-branch-merged: false
    when-current-commit-tagged: true
track-merge-target: false
track-merge-message: true
commit-message-incrementing: Enabled
regex: ''
source-branches: []
is-source-branch-for: []
tracks-release-branches: false
is-release-branch: false
is-main-branch: false

RepositoryFixture Test

No response

Output log or link to your CI build (if appropriate).

No response

[toadicusrex]

I added a comment on #4175 but I realized that it probably wouldn't get looked at as the issue is closed. Sorry about that.

[toadicusrex]

This is also alluded to in the issue #4139 which is marked as answered... But I explicitly don't want gitversion to give me the same semver for my release branch. In other words, I don't want to use ContinuousDeployment. I'm building nugets, and each commit on my master branch publishes a nuget, which throws an error if you're publishing the same nuget number (which would be a bad idea anyway, people have already downloaded the original artifact with that number). But ContinuousDelivery now with version 6 inserts the PreRelease tag on my master branch, which is a massive problem for my devops processes. This worked in version 5.

[Tilusch]

@toadicusrex the solution from #4175 worked for me it does increase the version if you incremented it with the right commit message. But i use the main branch as release branch

[toadicusrex]

I want every commit to master to increment, not just when I add a commit message (i.e. continuous delivery not continuous deployment). If I have it set for continuous delivery, I get a new updated version every time, but it adds the pre-release tag. If I have it set to continuous deployment I don't get the prerelease tag but I don't get a new version at all.

[toadicusrex]

I also use master as the release branch. I only create a "release branch" for hotfixes off of a specific tagged commit on master.

[toadicusrex]

@HHobeck Would you be willing to accept a PR that adds a property to branch configuration that toggles whether to prevent adding a prerelease tag? Tilusch's answer doesn't give me a solution, I'm willing to do a PR but I don't want to step on toes.

[toadicusrex]

Just further information - we've had gitversion working for quite a while, what I'm asking for was working in version 5... version 6 just broke it.

[HHobeck]

For me it is absolutely not clear what you are trying to achieve and if I'm honest this issue confusing me very much. I don't see a conceptual deficit at the moment. Before extending the configuration I would recommend you to start with the supported GitFlow (see Link[1]) or GitHubFlow (see Link[2]) workflow.

Anyway if you don't want a pre-release version number please use the ContinuousDeployment mode (like already mentioned).

If you are referring to the previous usage of Mainline mode (you need to name the child when you meant it): This mode and the algorithm behind has been deprecated and removed completely in version 6. Please see this discussion for more details:

• How to correctly migrate from V5 Mainline mode to V6 Mainline versioning without changes in behaviour? #4143

You can use the experimental TrunkBased workflow instead.

Cheers.

Link[1]: GitFlow Examples
Link[2]: GitHubFlow Examples

[toadicusrex]

I've seen responses on other threads basically detailing the same ideas that I'm expressing, though probably slightly different. Here's the situation.

Before extending the configuration I would recommend you to start with the supported GitFlow (see Link[1]) or GitHubFlow (see Link[2]) workflow.

I've been using GitVersion for about 8 years. As I specified above, I don't want to use either workflow.

Anyway if you don't want a pre-release version number please use the ContinuousDeployment mode (like already mentioned).

I also addressed this. If I don't use "ContinuousDelivery" I don't get a new version upon every commit.

I don't follow GitFlow or GitHubFlow. I want shorter lived work branches. That said, my primary goal is to deploy a production release upon every successful build in my devops process. I have tests that run as part of the build pipeline that (mostly) prevent builds that don't pass from getting deployed. The new process requires that I submit a tag in order to have a non-prerelease version created.

However... it takes my build server almost 30 minutes to build some of our legacy components. This means that when a commit happens, I run through the entire process, create a "production-capable" pre-release version of the components, which I've already tested and proven to be fully production-ready, mind you. Then, because I have to submit a tag to create a "non-prerelease" version, I am forced to build again in order to create a "stable" release.

Gitversion v6 works completely with that one exception. I don't want my main/master branch to add pre-release tags. That's it. Ever. All I really want is to be able to specify in the branch configuration that it should build a "stable" release upon every commit, not after every manual tag.

You can use the experimental TrunkBased workflow instead.

In the meantime, I will look at that workflow, and see if I can make it work. So far the reality of having to put a tag onto the branch seems to be consistent. I've already spent a week trying to fix our versioning in order to move to version 6 (onwards and upwards!) but this became a complete blocker. I'd be happy to contribute to this, I've pulled the source code and I'm digesting that and seeing where I might be able to contribute.

[HHobeck]

I also addressed this. If I don't use "ContinuousDelivery" I don't get a new version upon every commit.

Okay but then this has nothing to do with the fact a pre-release version is generated. It has something to do that you want to have on each commit a version increment (major, minor or patch) without defining a tag.

This was provided by using the Mainline mode in version 5. The other mode options (I can tell you) are behaving the same. In GitVersion (if we exclude the Mainline mode for a second) every commit is a pre-release version and remains until you are going to tag it. That's why it is not very constructive to tell me that it was working previously without given a hint that you are using the Mainline mode.

In the meantime, I will look at that workflow, and see if I can make it work.

Please try the following configuration:

workflow: 'TrunkBased/preview1'

or

workflow: 'GitHubFlow/v1'
strategies:
- Mainline
- ConfiguredNextVersion

I'd be happy to contribute to this, I've pulled the source code and I'm digesting that and seeing where I might be able to contribute.

I would appreciate it very much to get your contribution. The following open features are related to Mainline version strategy where we need help:

• [Feature]: Support of multi mainline branches in the Mainline version strategy #4057
• [FEATURE]: Support of '=semver: none|minor|major|patch' bump message to suppress the version increment #4144

At the end I want to say: Please understand that we cannot do a consultancy on every custom workflow for free. If you want you can engage me or other person of course. Best thing would be to isolate your problem and describe it with a concrete example with steps to reproduce based on one of the supported workflows.

Thank you for your understanding!