[Feature] Root configuration should propagate to branches

[Tognolo]

Hello, I'd like to use the GitVersionTask package to version my code, but I can't get information about it's configuration. I see a lot of configuration about the usage of the MsBuild setup, but it's not clear if the GitVersionTask package is enough or I've to install other packages. Any demo configuration is blessed.

[asbjornu]

You just install the NuGet package. Nothing else should be required.

[Tognolo]

I did it. But I can't get the right version in my libraries. E.g., I'm getting a version 2.4.0 for my DLLs, even if I didn't wrote that tag in any of my projects, neither in the code. Also, it's not clear which branch is using to work.

How can I run it in debug mode?

Edit: I just added the tag "2.3.8-alpha.1" to the develop (the previous one is "2.3.6") but I get the message "Failed to inherit Increment branch configuration, no branches found".

Edit 2: I'm renaming my tags to v2.x.x, but originally my tags are version/2.x.x, where I can setup the tag prefix using GitVersionTask package?

[asbjornu]

If you want more insight into why and how GitVersion calculates a given version number, I recommend you install the command line version and run it in the solution root. Its logs should give you an idea into what it bases the version number on. The command line is packaged in many different ways, so which one you should install is up to you. You can find the different variants detailed in #2326.

[Tognolo]

Running the command line gave me a better comprehension of how it works. Now I can ask a more specific question. I have the current tags sequences (and relative incremented versions):

• 2.3.9 (current tag) >> 2.3.9
• 2.3.8 >> 2.4.0
• 2.3.3 (the oldest, the previous ones are gone...) >> 2.4.0

In BaseVersionCalculator.GetBaseVersion it gets all the base versions and for each one calculates the incremented version, so for every commit it will be 2.4.0, except the current one. At this point there is:

var maxVersion = baseVersions
    .Aggregate((v1, v2) => v1.IncrementedVersion > v2.IncrementedVersion ? v1 : v2); // it is 2.3.8
var matchingVersionsOnceIncremented = baseVersions
    .Where(b => b.Version.BaseVersionSource != null && b.IncrementedVersion == maxVersion.IncrementedVersion)
    .ToList();

matchingVersionsOnceIncremented has every commit except the current one, because 2.3.9 < 2.4.0. At this point I need to understand how to:

• bump patch instead of minor value;
• set versioning mode to MainLIne.

Update

I was able to create the GitVersion.yml file in the right place with the right values. One question, as documentation says:

The part of the SemVer to increment when GitVersion detects it needs to be increased, such as for commits after a tag: Major, Minor, Patch, None.

The special value Inherit means that GitVersion should find the parent branch (i.e. the branch where the current branch was branched from), and use its values for increment, prevent-increment-of-merged-branch-version and tracks-release-branches.

But in ConfigExtensions.CalculateEffectiveConfiguration method the increment strategy is:

var incrementStrategy = currentBranchConfig.Increment.Value;

So the base setup is always overridden by branch configuration.

[asbjornu]

I'm happy you've figured out so much by yourself, @Tognolo. Can you please paste your GitVersion.yml file and explain which branches you have and version(s) you expect?

[Tognolo]

This is my GitVersion.yml:

tag-prefix: 'version\/|rc\/'
increment: None
branches: 
  develop:
    increment: None
  master:
    increment: None

I had to add the branches section to have the increment behaviour to None in develop and master branches. For the other branches the increment works as default, even if i set increment: None ad default setup. I expected that this configuration would be enough for my scenario:

tag-prefix: 'version\/|rc\/'
increment: None

[asbjornu]

I agree, this is something we should consider changing in v6.

[HHobeck]

I have thought about the concept. In my opinion we need to introduce a fallback and a unknown branch configuration. The fallback branch configuration might be (like in your example) be defined on the root configuration layer. But what I don't like with this solution is you do not see if it is related to the fallback setting or is it related to the overall setting of GitVersion.

Another solution might be to explicit separate the fallback-branch and unknown-branch configuration in a dedicated section with the same property like the normal branch configuration. This makes it quite clear what are branch configuration and what are overall configurations. At this moment there are also overlapping configurations (used for fallback and overall e.g. Increment or VersioningMode settings) which is error prone. If this is not complex enough the overall settings are leaking in the effected branch configuration as well.

Another problem I see is that you want to override an existing template (at this moment the default is the gitflow workflow template right?) or even want to define your workflow from scratch. How would you do this? If I'm right @asbjornu has already expressed an idea for templating.

[asbjornu]

@HHobeck, I'm not sure I understand what you mean with "templating". Can you please elaborate?