[Bug] Branch prerelease tags defined in branch configuration in gitversion.yml seems to be ignored if a version tag points at the same commit as the branch and using mainline for the branch in question

[hallgeir-osterbo-visma]

Describe the bug A clear and concise description of what the bug is.

Branch prerelease tags defined in branch configuration in gitversion.yml seems to be ignored if a version tag points at the same commit as the branch and using mainline for the branch in question.

The state in which this is happening is if:

• The branch config (for e.g. release branches) has is-mainline: true
• AND there's a tag (e.g. v2.0) with the same commit id as the head of the branch

If I set is-mainline: false on the branch, we do get a prerelease tag.

I'm wondering if this is expected behavior or not for gitversion, or if it's a bug.

Expected Behavior

I would think that the branch config should be applied even if there is a version tag pointing to the exact same commit as the branch. In the example given in the sample repo under "Steps to Reproduce", I would expect e.g. "PreReleaseLabel" to be output as "release". Instead it's empty.

Actual Behavior

The branch config is ignored and the prerelease tag is not added. In the example given in the sample repo under "Steps to Reproduce", e.g. "PreReleaseLabel" is output as an empty string.

Possible Fix

Steps to Reproduce

Using the following gitversion.yml:

assembly-versioning-scheme: MajorMinorPatch
assembly-file-versioning-scheme: MajorMinorPatch
mode: Mainline
continuous-delivery-fallback-tag: ''
tag-prefix: '[vV]'
branches:
  main:
    tag: ''
    increment: Patch
    prevent-increment-of-merged-branch-version: true
    track-merge-target: false
    regex: ^master$
    source-branches: []
    tracks-release-branches: false
    is-release-branch: false
    is-mainline: true
    pre-release-weight: 0
    is-source-branch-for:
    - release

  release:
    tag: release
    increment: Patch
    prevent-increment-of-merged-branch-version: true
    track-merge-target: false
    regex: ^release?[/-]
    source-branches:
    - main
    tracks-release-branches: false
    is-release-branch: true
    is-mainline: true

1. On some repo, from the master/main branch, create a tag e.g. v2.0: git tag v2.0
2. Create a release branch from the same commit: git checkout -b release/2.0
3. Run gitversion and see that even though the branch config specifies that we should have a "-release" prerelease tag, that prerelease tag is missing.
4. If I do a commit (can be an empty one) to the release branch, then I get a prerelease tag as expected.

I have created a repo here: https://github.com/hallgeir-osterbo-visma/gitversion-test which has a minimal example. Simply clone the repo, checkout release/2.0, and run "gitversion" on the root of the repo after.

Context

When we create new release branches, we trigger all our builds to build deployment packages for our CD system. We also tag the code with a version tag (e.g. v2.0). We require these packages to have a -release prerelease tag to distinguish them from packages produced from our master/dev branches. But if we trigger our builds right after we create the version tag, we get packages produced without the -release prerelease tag, which we don't want.

Your Environment

• Version Used: 5.10.3 (same behavior for 5.6.9)
• Operating System and version (Windows 10, Ubuntu 18.04): Windows
• Link to your project: Created a minimal project here: https://github.com/hallgeir-osterbo-visma/gitversion-test
• Link to your CI build (if appropriate):

[asbjornu]

Why are you setting is-mainline: true on your release branch in the first place?

[hallgeir-osterbo-visma]

The reason is that we need the patch version to increment when we do new commits to the release branch. We need package versions to be unique . If I set is-mainline: false on the release branch, that doesn't seem to happen.

If there are better ways of solving this, that allows me to set is-mainline: false on release branches, then I'd welcome that very much. It would solve my issue.

[asbjornu]

Try increment: Patch and mode: ContinuousDeployment.

[hallgeir-osterbo-visma]

I tested this now, but for some reason the patch is not incremented automatically on additional commits. That's the reason why we went with mode: mainline back when we set this up. I may be missing something obvious though.

For the record, this is the config:

assembly-versioning-scheme: MajorMinorPatch
assembly-file-versioning-scheme: MajorMinorPatch
mode: ContinuousDeployment
continuous-delivery-fallback-tag: ''
tag-prefix: '[vV]'
branches:
  main:
    tag: ''
    increment: Patch
    prevent-increment-of-merged-branch-version: true
    track-merge-target: false
    regex: ^master$
    source-branches: []
    tracks-release-branches: false
    is-release-branch: false
    pre-release-weight: 0
    is-source-branch-for:
    - release

  release:
    tag: release
    increment: Patch
    prevent-increment-of-merged-branch-version: true
    track-merge-target: false
    regex: ^release?[/-]
    source-branches:
    - main
    tracks-release-branches: false
    is-release-branch: true

I suppose I could use CommitsSinceVersionSource instead of Patch to build my final version number -- is there any drawbacks to that?

[asbjornu]

Correct, it is only CommitsSinceVersionSource that increments on commits. increment: Patch only tells GitVersion to increment patch in relation to the version source (usually the last git tag on main). If you need patch to increment with every commit, you need to compose your own version number with CommitsSinceVersionSource as you suggest.

However, be aware that CommitsSinceVersionSource will reset at various different events in your repository and can as such not be considered a stable, ever-incrementing, variable.

The way to ensure unique package names is to use mode: ContinuousDeployment and FullSemVer which will include PreReleaseTag that also includes CommitsSinceVersionSource. Is there a reason why you can't use FullSemVer?

[hallgeir-osterbo-visma]

Thanks for the confirmation!

The reason why we don't use FullSemVer is that in our deployment system, we use the prerelease tags to determine which environments we're deploying to (e.g. release vs hotfix). May not be optimal, and we may be able to solve this differently to be able to use FullSemVer - but it would require some rework of what we have.

Then I think CommitsSinceVersionSource will be the way we go. For now at least.

Thanks a lot for your feedback on the issue!