Master branch is not setting appropriate version after PR'ing releases/ branch into it.

[AndrewMcClelland]

No description provided.

[asbjornu]

GitVerison can't base the version number of master on the name of another branch, since that branch is going to be deleted in the future. Git does not preserve branch names alongside the commits. The branches point to commits, not the other way around.

So even though it would be possible for GitVersion to generate the version number 1.5.0 on master on the commit release/1.5.0 being merged into master, that's only possible while release/1.5.0 still exists. Fast forward 2 years, GitVersion still needs to be able to mint version 1.5.0 from the same merge-commit, but since release/1.5.0 is no longer existent, it's impossible for GitVersion to do so.

[timmyWelling]

The difference between the local test and ADO is likely the wording of the merge commit message. ADO is probably adding some prefix that disrupts GitVersion's default regex used to parse the branch name from the merge commit message. Like @asbjornu mentioned the branch isn't preserved, so GitVersion parses the merge commit to figure out where a branch merge occurred (e.g. Merged releases/1.5.0 into master). If the branch name is successfully parsed, the correct version should be calculated automatically.

Check this documentation for an example: https://gitversion.net/docs/configuration#merge-message-formats

[timmyWelling]

You can test locally by manually recreating the same message used by TFS, and the output should tell you if it used your custom parser. My guess is remove the brackets in your config file.

[timmyWelling]

If you run GitVersion with the /output buildserver option, you will see the full version calculation logs. If the merge-message-parser regex matched on a commit, it will say 'Found commit x matching merge message format:tfs'. I believe you can change to ado.