[Bug] tag & increment override not working

[dxynnez]

Describe the bug
Hi there, I am new to gitversion and currently trying to setup our CI to integrate with it. But can't really get it to work the way we wanted.

We have develop branch that our daily PR would go into with the following config:

next-version: 1.0.0
assembly-versioning-scheme: MajorMinorPatch
assembly-informational-format: '{InformationalVersion}'
mode: ContinuousDelivery
increment: Inherit
tag-prefix: '[vV]'
continuous-delivery-fallback-tag: alpha
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)'
commit-message-incrementing: Enabled
branches:
  release:
    regex: release
    source-branches: [ 'develop' ]
    mode: ContinuousDelivery
    tag: ''
    increment: Minor
    prevent-increment-of-merged-branch-version: false
    track-merge-target: true
    tracks-release-branches: false
    is-release-branch: true
  develop:
    regex: develop
    source-branches: []
    mode: ContinuousDelivery
    tag: 'beta'
    increment: Patch
    prevent-increment-of-merged-branch-version: false
    track-merge-target: true
    tracks-release-branches: true
    is-release-branch: false
ignore:
  sha: []

I am trying this out with a new repo without any tag. Running gitversion would give me:

{
  "Major":1,
  "Minor":0,
  "Patch":0,
  "PreReleaseTag":"beta.1",
  "PreReleaseTagWithDash":"-beta.1",
  "PreReleaseLabel":"beta",
  "PreReleaseLabelWithDash":"-beta",
  "PreReleaseNumber":1,
  "WeightedPreReleaseNumber":1,
  "BuildMetaData":2,
  "BuildMetaDataPadded":"0002",
  "FullBuildMetaData":"2.Branch.develop.Sha.44c87b430b3d503c7a6ce1b0298161f8464943c6",
  "MajorMinorPatch":"1.0.0",
  "SemVer":"1.0.0-beta.1",
  "LegacySemVer":"1.0.0-beta1",
  "LegacySemVerPadded":"1.0.0-beta0001",
  "AssemblySemVer":"1.0.0.0",
  "AssemblySemFileVer":"1.0.0.0",
  "FullSemVer":"1.0.0-beta.1+2",
  "InformationalVersion":"1.0.0-beta.1+2.Branch.develop.Sha.44c87b430b3d503c7a6ce1b0298161f8464943c6",
  "BranchName":"develop",
  "EscapedBranchName":"develop",
  "Sha":"44c87b430b3d503c7a6ce1b0298161f8464943c6",
  "ShortSha":"44c87b4",
  "NuGetVersionV2":"1.0.0-beta0001",
  "NuGetVersion":"1.0.0-beta0001",
  "NuGetPreReleaseTagV2":"beta0001",
  "NuGetPreReleaseTag":"beta0001",
  "VersionSourceSha":"db76655c3c4073441eaeb2bbd421d80018251492",
  "CommitsSinceVersionSource":2,
  "CommitsSinceVersionSourcePadded":"0002",
  "UncommittedChanges":1,
  "CommitDate":"2021-09-17"
}

I then tag the latest commit with git tag "v1.0.0-beta", then add another commit with git commit --allow-empty -m "noop"
I was expecting the next gitversion to be 1.0.1-beta now but it didn't change. If I tag the commit without the '-beta' tag then this would work, though. Is this expected? Is there any way to tag the commit with full semver format and still have it to be recognized by gitversion?

Also, after merging the commit to release and tag the merge commit with "v1.1.0", running gitversion on the develop branch would still give me the old version number (1.0.1), adding another empty commit would result in 1.0.2 (I was expecting it to be 1.1.0) at this point since I set track-merge-target: true. Is this also expected?

We would like to achieve that, with each individual commit into develop, only the patch version would be bumped. We do weekly merge from develop -> release and with that the minor version would be bump and reset patch version back to zero (so that we know it includes all the patches in the previous minor version). Then we want the develop branch to pickup the new minor version and start a new cycle. Is this indeed possible with gitversion? Thanks in advance!

[asbjornu]

Try changing mode: ContinuousDelivery to mode: ContinuousDeployment. Does that help?

[dxynnez]

Try changing mode: ContinuousDelivery to mode: ContinuousDeployment. Does that help?

@asbjornu thanks for looking into this! I actually tried playing around with different modes but the behavior didn't seem to change.

I guess I should have summarized my questions a bit more:

1. Would gitversion work if my commits are tagged with a semver quality suffix? e.g. v1.0.0-beta
2. What exactly does the 'track-merge-target: true' do when calculating the version number? In case of a merge, would the source branch be able to detect the version changes in the target branch and update its own version accordingly? e.g. develop (v1.0.5-beta) merged into release(v1.0.0 -> v1.1.0) results in develop version starts from v1.1.0-beta

[eFloh]

I can confirm this. for mainline there's a similar showstopper:

When a commit is tagged with prerelease-tag (e.g. -beta.1), the mainline will use that commit as new commit count source, but does not increment its version number.
that means, the mainline prerelease commit count jumps backwards.

e.g.

// increment: patch, release/* are release branches, not tracked.

tag v1.0.0
//version is v1.0.0
commit 1
//mainline is v1.0.1-unstable.1
branch release/v1.1.0
// mainline is v1.0.1-unstable.1
// branch is v1.1.0-beta.1 
commit 2
// mainline is v1.0.1-unstable.2
tag v1.1.0-beta.1 release/v1.1.0
// mainline changes back to v1.0.1-unstable.1
// branch is still v1.1.0-beta.1 

cause: the beta-version tag is used as version source and commit count.
expected: the beta-version tag should only be used for the very tagged commit, but not as commit count source for mainline.
only "final" versions should be a commit count source.

when the beta tag would be considered version source, mainline should be 1.1.1 after the beta tag is created, as it is for a final version tag. but that causes jumping back in mainline when a new beta is created "in between".

[dxynnez]

Hi @asbjornu , just checking in - do you have any idea for the above questions?

[asbjornu]

@dxynnez does removing next-version: 1.0.0 help? You have a quite massive GitVersion.yml there. I would even suggest to delete it entirely and just add overrides for whatever you want to change from the defaults.

[HHobeck]

This issue is probably related to #3438.

1. What I'm suprised with is that you are expecting that after tagging a pre-release version the minor, major or patch number should be increasing. That is not the behavior of GitVersion. Like the name indicates it is a pre-release label for versions which are not yet released but somehow provided to user.

2. The track-merge-target option was a broken feature which has been revitalized in the PR Ensure track-merge-target: Strategy which will look for tagged merge commits directly off the current branch #3406. This comment [Bug] track-merge-changes produces unexpected result when combining hotfix and support branches #3052 (comment) is a good example of a use case.

track-merge-target

Strategy which will look for tagged merge commits directly off the current branch. For example develop → release/1.0.0 → merge into master and tag 1.0.0. The tag is not on develop, but develop should be version 1.0.0 now.