Hardy Hobeck

> > Actually this PR has no breaking changes (from the feature point of view) and doesn't break any tests (except those tests who are false positive ;)). > >...

Or this example is a good one to highlight. No one can seriously expect the version 1.1.0 on the develop branch: ```csharp [Test] public void InheritVersionFromReleaseBranch() { using var fixture...

Just to understand your scenario: You expecting that GitVersion detects the version 2.1.0 from the release branch with the name release/R2112?

> Hello @micdenny, Do you think your PR should fix this use case ? > > ```cs > [Test] > public void CalculatesCorrectVersionWhenPullRequestHotfixBranchToMain() > { > using var fixture =...

Have you tried to use GitVersion with the parameter gitversion /c {commit-id}? Please see gitversion /help for more information. ``` # Remote repository args ... /c The commit id to...

> If no one objects, I'd like to conclude this discussion with renaming tag to label. PRs welcome. I like your idea to rename it to label. :)

Please see the discussion in #3052. I would like to fix this issue and know for sure (like you already said) that the track-merge-target is without function. This feature has...

In TrackReleaseBranchesVersionStrategy.cs you find the following logic: ```csharp private IEnumerable MainTagsVersions() { var configuration = this.context.Value.Configuration.Configuration; var main = this.repositoryStore.FindMainBranch(configuration); return main != null ? this.taggedCommitVersionStrategy.GetTaggedVersions(main, null) : Array.Empty(); }...

> This may be related to https://github.com/GitTools/GitVersion/pull/3190. It may also be worth trying to change the configuration so production is identified as main and main is identified as develop. Actually...

> I suppose so. I believe a branch being considered main only affects itself and its own versioning strategy. I don't think other branches should be affected by one or...