Different result past version 6

[Dunge]

So I'm using the same build process since over a decade, it's probably not correct and would like guidance.

What we usually do is very simple:

• Developers works on branch develop directly (we are only a few, no need for feature branches)
• Once a main release is ready, we merge develop on master, create a tag of the new version, push, then merge master back on develop
• GitVersion will compute a version for master and use the new tag (ex: 3.141)
• GitVersion will also compute a new version for develop doing +1 on the minor and adding alpha for the number of commits on develop since that version (ex: 3.142-alpha0052)

Our GitVersionConfig.yaml file is set to mode: ContinuousDelivery

Now the next release tag for develop was working fine with GitVersion 5, but not if I update to 6:

dotnet-gitversion
"FullSemVer": "3.142.0-alpha.1",

dotnet tool update gitversion.tool -g
Tool 'gitversion.tool' was successfully updated from version '5.7.0' to version '6.0.5'.

dotnet-gitversion
"FullSemVer": "3.141.0-alpha.88",

I tried running with /diag to see what's going on, but I can't say I'm able to understand what is getting printed. But I do see this line near the end:

INFO [24-11-13 12:32:37:46] 88 commits found between '4b7bcd5' - Merge branch 'release3.140.2' and '2c14306' - Merge branch 'master' into develop

[HHobeck]

GitFlow Examples - Develop Branch:

Please notice that the sequence diagram above (which covers your scenario) is generated from an automated integration test. I would recommend you to read the documentation.

[Dunge]

Yeah I assumed as much. So what is it then? Why doesn't my minor version automatically increase in my develop branch like before? It is the branch names (master vs main), or the release branch that would need a particular name (I suppose not)? Maybe some other new field that needs to be specified in the config file?

I'm sorry but "read the doc" isn't much helpful here, there's nothing in the text being specific about it, and the graph here isn't particularly clear what causes the develop branch to go from 1.3.0 to 1.4.0 other than a cut line. Logically I would expect it would be after getting merged from a main branch who received a new tag, but it seems to happens before that in the chart?

It also doesn't explain why the behavior changed in the last GitVersion release.

[HHobeck]

I don't know either. You need to analyze your use case and take a look how the repository state looks like. Maybe you should start with a simple HelloWorld repository to simulate your workflow by using native git commands.

[HHobeck]

Please analyse your issue in more detail and find out the root cause. It is not constructive to say it was working in the previous version. Please isolate your scenario in version 6 and create simplified steps to reproduce.

I'm going to close this discussion. Thank you for your understanding.

[Dunge]

That's not helpful either. I'll stay with version 5 until you fix your issues

[HHobeck]

I'm sorry if you are not satisfied with my answer. But do you really think it would be better to not give an answer and leave your problem open forever!? Because this will happen trust me. If you don't analyze your problem, who else will do this for you?

And also if someone wants to invest time, how would it be possible without any steps to reproduce or to have access to your git repository? You have not provided any logs or even which configuration you are using or how the git history looks like. The only thing I see is your workflow description that is covered in the GitFlow/v1 workflow (which I have pointed out).

Last but not least, it's not too much to ask for to replay your scenario in a simplified HelloWorld repository with native git commands. Because by doing this you would find out what the root cause might be by yourselve.

I wish you all the best.

[Dunge]

I found my answer by reading the document here:

https://github.com/GitTools/GitVersion/blob/main/BREAKING_CHANGES.md

(This should definitely be part of the documentation website, it's extremely hard to find).

I had two problems:

1. GitVersionConfig.yaml stopped being used. The config file should now be named GitVersion.yml
2. A new settings called semantic-version-format was introduced and set to Strict by default which prevent tags with only two digits to be used. For example 3.141 isn't valid, but 3.141.0 is. Setting it to Loose brought back the old behavior.

@HHobeck This is the kind of changes you should be aware of and refer to users when they have problem instead of saying "read the doc" pointing to a document that doesn't have this information and closing the question without trying to suggest methods to diagnose and help.

[Dunge]

But since Visual Studio support was dropped in V6, and I need both (msbuild nuget version for visual studio while developing, and dotnet tool version for the build machine), and the config file is not compatible, I'll remain on version 5 anyway until visual studio support come back.