Why do version numbers in branch names change the calculated version?

[bert2]

Problem

Since GitVersion 4 we noticed a suddend jump in the version generated by GitVersion. Looking at the diagnostic output it seems to respect a version number in the name of a merged branch. That is not intended though, because the version number in the branch name is purely coincidental:
bugfix/COCO-1266-ng-bootstrap-ng-bootstrap-2.2.0.

The 2.2.0 in the branch name seems to cause a bump to 2.3.0 on develop:

> gitversion /showvariable FullSemVer
2.3.0-alpha.1351

The previous version of GitVersion correctly calculated 1.8.0.

Question

I'm wondering whether this behavior can be configured? Maybe there is a regex somewhere that we need to adjust?

Additional Info

I figured we could set next-version or use a git tag as a workaround.

We are currently using an "unconfigured" (no GitVersion.yml) installation of GitVersion 4.0.0:

> choco list -l GitVersion.Portable
Chocolatey v0.10.8
GitVersion.Portable 4.0.0
1 packages installed.

Here's the diagnostic output:

> gitversion /showvariable FullSemVer /diag
INFO [11/19/18 13:58:01:60] Dumping commit graph: 
...

INFO [11/19/18 13:58:01:72] Working directory: C:\dev\contracting
INFO [11/19/18 13:58:01:72] IsDynamicGitRepository: False
INFO [11/19/18 13:58:01:74] Returning Project Root from DotGitDirectory: C:\dev\contracting\.git - C:\dev\contracting
INFO [11/19/18 13:58:01:74] Running on Windows.
INFO [11/19/18 13:58:01:74] IsDynamicGitRepository: False
INFO [11/19/18 13:58:01:74] Returning Project Root from DotGitDirectory: C:\dev\contracting\.git - C:\dev\contracting
INFO [11/19/18 13:58:01:74] Project root is: C:\dev\contracting
INFO [11/19/18 13:58:01:74] DotGit directory is: C:\dev\contracting\.git
INFO [11/19/18 13:58:01:75] IsDynamicGitRepository: False
INFO [11/19/18 13:58:01:75] Returning Project Root from DotGitDirectory: C:\dev\contracting\.git - C:\dev\contracting
INFO [11/19/18 13:58:01:79] IsDynamicGitRepository: False
INFO [11/19/18 13:58:01:79] Returning Project Root from DotGitDirectory: C:\dev\contracting\.git - C:\dev\contracting
INFO [11/19/18 13:58:01:80] Using latest commit on specified branch
INFO [11/19/18 13:58:01:82] Running against branch: develop (a812a30ef3fe2fa6e8c98d11edac766a977ebc9f)
INFO [11/19/18 13:58:01:83] Begin: Calculating base versions
  INFO [11/19/18 13:58:01:97] Fallback base version: 0.1.0 with commit count source 273b1c079ff02f564f54b3cb06c272f07116d8f4 (Incremented: None)
  INFO [11/19/18 13:58:02:31] Git tag '1.6.0': 1.6.0 with commit count source 4af704417ba5a3d9dce22599d32f0db5f0018bdf (Incremented: 1.7.0)
  INFO [11/19/18 13:58:02:33] Git tag '1.5.0': 1.5.0 with commit count source b5f6f313cea96adbcd3c7a541fdb9728fb1e51da (Incremented: 1.6.0)
  INFO [11/19/18 13:58:02:36] Git tag '1.4.0': 1.4.0 with commit count source c391c7e7b9e76cfd7b0478e06b4aa7713abc7687 (Incremented: 1.5.0)
  INFO [11/19/18 13:58:02:39] Git tag '1.3.0': 1.3.0 with commit count source 3b7bd6a70184061f1780752017fcaed8fe0c7ae8 (Incremented: 1.4.0)
  INFO [11/19/18 13:58:02:56] Merge message 'Merge pull request #159 in ITD/contracting from bugfix/COCO-1266-ng-bootstrap-ng-bootstrap-2.2.0 to develop

* commit '079e3ed489ce4da8195e20f9225030155128eefd':
  COCO-1266: changed css so card-header will have less height again.': 2.2.0 with commit count source 795ef6078ed0a7ccba1ff9f473a80cd884cf3e54 (Incremented: 2.3.0)
  INFO [11/19/18 13:58:02:66] Git tag '1.7.0': 1.7.0 with commit count source d59beaf2be8ae73bc6e7a21e30c66e87d93cf645 (Incremented: 1.8.0)
  INFO [11/19/18 13:58:02:67] Git tag '1.6.0': 1.6.0 with commit count source 4af704417ba5a3d9dce22599d32f0db5f0018bdf (Incremented: 1.7.0)
  INFO [11/19/18 13:58:02:69] Git tag '1.5.0': 1.5.0 with commit count source b5f6f313cea96adbcd3c7a541fdb9728fb1e51da (Incremented: 1.6.0)
  INFO [11/19/18 13:58:02:72] Git tag '1.4.0': 1.4.0 with commit count source c391c7e7b9e76cfd7b0478e06b4aa7713abc7687 (Incremented: 1.5.0)
  INFO [11/19/18 13:58:02:75] Git tag '1.3.0': 1.3.0 with commit count source 3b7bd6a70184061f1780752017fcaed8fe0c7ae8 (Incremented: 1.4.0)
  INFO [11/19/18 13:58:02:77] Found multiple base versions which will produce the same SemVer (2.3.0), taking oldest source for commit counting (Merge message 'Merge pull request #159 in ITD/contracting from bugfix/COCO-1266-ng-bootstrap-ng-bootstrap-2.2.0 to develop

* commit '079e3ed489ce4da8195e20f9225030155128eefd':
  COCO-1266: changed css so card-header will have less height again.')
  INFO [11/19/18 13:58:02:78] Base version used: Merge message 'Merge pull request #159 in ITD/contracting from bugfix/COCO-1266-ng-bootstrap-ng-bootstrap-2.2.0 to develop

* commit '079e3ed489ce4da8195e20f9225030155128eefd':
  COCO-1266: changed css so card-header will have less height again.': 2.2.0 with commit count source 795ef6078ed0a7ccba1ff9f473a80cd884cf3e54 (Incremented: 2.3.0)
INFO [11/19/18 13:58:02:78] End: Calculating base versions (Took: 945.00ms)
INFO [11/19/18 13:58:02:83] 1351 commits found between 795ef6078ed0a7ccba1ff9f473a80cd884cf3e54 and a812a30ef3fe2fa6e8c98d11edac766a977ebc9f
INFO [11/19/18 13:58:02:84] Begin: Getting version tags from branch 'refs/heads/develop'.
INFO [11/19/18 13:58:02:94] End: Getting version tags from branch 'refs/heads/develop'. (Took: 100.00ms)

[asbjornu]

You can use ignore in GitVersion.yml to ignore the problematic commits, either by their SHA or before a given date. It would be neat if branch number version sourcing was configurable, for instance ignoring version numbers in all other branches than release/*, but that's unfortunately not possible at the moment. Pull requests for such functionality are welcome, though.

[asbjornu]

A tool that makes this problem escalate fairly quickly is Dependabot. Its branch names for package upgrade pull requests contains both "from" and "to" version numbers of the package being requested for upgrade, which causes GitVersion to generate quite crazy version numbers from a source that shouldn't be used at all. And as per dependabot/dependabot-core#396, there's little chance this will be fixed on Dependabot's side. We need to fix our version sourcing. 😃

[bert2]

Thanks for the hint to ignore!

I'm working on a PR. The current solution uses a global configuration flag to indicate that branches must match the release branch regex to be considered as a version source.

But maybe I should skip the configuration flag (or inverse it) and make this the default behavior?

Another way might be to configure per branch if it is to be considered as a version source.

What do you think?

[bert2]

By the way excellent job on those tests! They made it super easy to get started.

[bert2]

Thinking about it again, it's probably smarter to evaluate is-release-branch of a branch config.

[bert2]

I created a pull request to fix the behavior by configuration.