Different versions after upgrading GitVersion from version 5 to 6

[lbass2]

Hello there,

I've looked through the other discussions and through the documentation, but I did not find anything helpful, so that's why I'm asking here for help.

In my company, we are hosting our code on Azure DevOps. We are also utilizing Pipelines for CI stuff and to create Nuget packages from our sources.
Recently, I've decided to upgrade the build pipeline to use GitVersion 5 instead of 6. After some initial trouble I thought everything was looking good, but then I spotted a difference in the calculated version.

My environment:

Azure Pipeline GitVersion Tasks

3.0.0

GitVersion

6.0.3

Setup

We use GitFlow, so we have use following branches:

• develop
• master
• feature
• release

GitVersion.yml

My config file looks like this (sorry, code formatting seems not to like my YML content, so here is a screenshot):

Steps to reproduce

When work starts on a new feature a branch "feature/12345-FEATURENAME" is branched from develop.
The following output was created from a freshly created feature branch, with only one commit (to have a change at all).

What are you seeing?

With GitVersion 6, the output is the following:

{
  "AssemblySemFileVer": "12.34.0.0",
  "AssemblySemVer": "12.34.0.0",
  "BranchName": "feature/987654-testfeature",
  "BuildMetaData": null,
  "CommitDate": "2024-10-28",
  "CommitsSinceVersionSource": 689,
  "EscapedBranchName": "feature-987654-testfeature",
  "FullBuildMetaData": "Branch.feature-987654-testfeature.Sha.0b79a0ac1bb63f9078b36027a3125d55fdf13247",
  "FullSemVer": "12.34.0-Feature.987654-testfeature.689",
  "InformationalVersion": "12.34.0-Feature.987654-testfeature.689+Branch.feature-987654-testfeature.Sha.0b79a0ac1bb63f9078b36027a3125d55fdf13247",
  "Major": 12,
  "MajorMinorPatch": "12.34.0",
  "Minor": 34,
  "Patch": 0,
  "PreReleaseLabel": "Feature.987654-testfeature",
  "PreReleaseLabelWithDash": "-Feature.987654-testfeature",
  "PreReleaseNumber": 689,
  "PreReleaseTag": "Feature.987654-testfeature.689",
  "PreReleaseTagWithDash": "-Feature.987654-testfeature.689",
  "SemVer": "12.34.0-Feature.987654-testfeature.689",
  "Sha": "0b79a0ac1bb63f9078b36027a3125d55fdf13247",
  "ShortSha": "0b79a0a",
  "UncommittedChanges": 0,
  "VersionSourceSha": "5d2bd7504ca09b903a949f3c34ee9090a38176f1",
  "WeightedPreReleaseNumber": 30689
}

The build number is set to the following:

Update build number to 12.34.0-Feature.987654-testfeature.689 for build 97953

The same branch, but with GitVersion version 5 (of course with old GitVersion.yml). Output looks a little bit different, but the task updates the build number to the following

Update build number to 12.34.0-Feature.987654-testfeature.1+47 for build 97976

What is expected?

The problems I've not been able to solve yet:

• The used source version used to calculate the commit count has changed, resulting in a way higher commit count. For now that is only a cosmetic problem, but still looks quite odd. I would have expected this to be like 0 (or 1 after the first commit), as I expected the source to be the last common commit on develop (develop is tagged after each merge on it).
• The suffix seems to have changed (what comes after the branch name, in this case after "testfeature"):
  • GitVersion 5: ".1+47". The "1" will only increase after this branch is tagged with the build number.
    In our workflow, this happens when a feature branch is released (release = taging + nuget packages from source). So for a new feature branch, this count starts by 1. After it gets tagged the next version will be like ".2+XY", after the next release ".3+XY" and so on. So this also indicated how many releases were created from builds on that feature branch.
  • GitVersion 6: Now, the suffix only consists of the "commits since version source", while the "tag counting" is missing.

I tried quite a lot, but I wasn't able to get the "old versioning" style back. Any help is appreciated!

Thanks and best regards
Lorenz

[HHobeck]

Please read the documentation first and use the supported workflows e.g. GitFlow/v1 before starting customizing.

• Configuration
• Versioning Modes
• GitFlow Examples

What I can tell you is that the meaning of Continuous Delivery has changed in version 6 and replaced with Manual Deployment.

Generally we cannot helping out with custom workflows. But if you want you can engage me or other person to help you and build custom workflows.

Thank you for your understanding.