[Bug] gitversion /diag and gitversion produce different version output

[cekay79]

Hi Everyone,

this might be also a problem of understanding what should happen but I also experienced unusual behaviour between two recent versions of gitversion (5.6.4 and 5.6.6).

I was trying to find out what needed to be done in terms of merging and tagging so that gitversion correctly bumps my version of "develop" branch after I merged a release branch back to master and deleted the release branch (without merging it back to develop because i didnt to any changes on it).

Layout used was: gitversion, standard gitflow using the wizard. What I did (see steps to reproduce for detailed description)

Created master 1.0.0 (via tag) Branched develop, made changes and branched of releases/1.1.0 and tagged the first beta 1.1.0-beta.1 Went back to develop, made a change. Went to master merged back the release branch and tagged it 1.1.0 Went back to develop and deleted the releases 1.1.0 releases branch (without merging it back to develop because it didnt had a change)

Expected Behavior

According to my understanding of gitversion together with gitflow is, that even if I dont merge anything back from a release branch to develop it should see the merged release to master and / or the tag on master and version bump the develop branch. I was expecting develop to version bump to 1.2.0 alpha even if after I deleted the release branch.

Actual Behavior

gitversion doesn't do the version bump if I remove the release branch older gitversion /diag (from my perspective) correctly outputs the bumped version of develop I was seeing that develop was 1.2.0-alpha.. before i deleted the release branch and it went back to 1.1.0 alpha after it.

Steps to Reproduce

mkdir foo cd foo touch testfile git init gitversion (wizard -> 1 -> 1 -> save changes) git add GitVersion.yml testfile git commit -a -m "initial release" git tag v1.0.0 git checkout -b develop echo "change1" > testfile git commit -a -m "change1 on develop" git checkout -b releases/1.1.0 git tag v1.1.0-beta.1 git checkout develop echo "change2" > testfile git commit -a -m "change2 on develop" git checkout master git merge --no-ff releases/1.1.0 git checkout develop (is 1.2.0-alpha.1) here git branch -d releases/1.1.0

gitversion 5.6.6 outputs semver 1.1.0-alpha.2 for develop gitversion 5.6.4 outputs semver 1.1.0-alpha.2 for develop gitversion 5.6.4 /diag outputs 1.2.0-alpha.1 for develop (!)

Context

Your Environment

• Version Used: gitversion 5.6.6 (with 5.6.4 for reference)
• Operating System and version (Ubuntu 20.04):
• Link to your project: n/a
• Link to your CI build (if appropriate): n/a

[asbjornu]

After merging release branches, you need to add a tag to master. Since the release branch will most likely be deleted after it is merged, it can't be used as a version source.

[DarkStarDS9]

I am troubleshooting a related issue right now - having an unexpected version when running gitversion, but getting the expected version when running gitversion /diag. After looking at the source, I noticed that diag enforces nocache, and sure enough running gitversion /nocache also gives the expected version.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs.

[HHobeck]

I have tried to reproduce this issue with the 6.0.0-beta.7 version of gitversion and don't see any different behavior when using the -diag parameter. I'm getting in both cases 1.1.0-alpha.1 as a result on the develop branch which is correct.

After merging release branches, you need to add a tag to master. Since the release branch will most likely be deleted after it is merged, it can't be used as a version source.

I agree with the statement but even if you do this it has no effect on the run on the development branch because the tag is in the future (from the point of view of the head commit in develop branch) and thus it will be not considered. That means until you are not merging from main back to develop branch the version 1.1.0-alpha.1 will be determined instead of 1.2.0-alpha.1 even you are tagging the commit on the main branch. Hope that understandable.

I'm going to close this issue because it is not a bug.