CommitsSinceVersionSource should not decrease upon merging a release branch into develop

[ruhullahshah]

CommitsSinceVersionSource decreases when a release branch is merged to develop and PreventIncrementOfMergedBranchVersion is set to true.

For now I have added a minimalistic testcase, exhibiting the problem defined in issue #2505.

[ruhullahshah]

@asbjornu @arturcic Happy New Year!
Is this expected behavior with the config presented in the testcase? In my opinion, no. I find the documentation on PreventIncrementOfMergedBranchVersion to be not so informative to decide this completely on my own.

[asbjornu]

Happy new year, @ruhullahshah! 🎉 I think the test looks fine and that it should be successful. It would be great if the PR could also contain a clarification of the docs on PreventIncrementOfMergedBranchVersion.

[asbjornu]

Suggested change

	public void WhenPreventIncrementOfMergedBranchVersionIsSetToTrueCommitsSinceVersionSourceShouldNotGoDownWhenMergingReleaseToDevelop()
	public void WhenPreventIncrementOfMergedBranchVersionIsSetToTrue_AndMergingReleaseToDevelop_CommitsSinceVersionSourceShouldNotDecrement()

[ruhullahshah]

@asbjornu Thanks for the feedback. I would love to enhance the documentation, however, to be honest, I am not so thorough with the use cases that PreventIncrementOfMergedBranchVersion targets. Having said that, I am sure constructing the fix for this PR would unearth some of the intended use cases, but please feel free to add your thoughts that you think should be added to the relevant docs.

[ruhullahshah]

@asbjornu Updated the docs

[ruhullahshah]

Analysis

Commit Graph

The commit graph corresponds to the repository state after merging the release branch to develop (Line 319 of DevelopScenario.cs) and commits from this graph will be referred to, for explaining the observed behavior

1. Why does the CommitsSinceVersionSource decrease in this scenario?

• The base version calculation strategies yield the following list of candidate versions:

baseVersions
Count = 5
    [0]: {Fallback base version: 0.1.0 with commit count source 2afdc59845ce1c76975a5d5c09e708d0e2c31de3 | 0.1.0}
    [1]: {Merge message 'Merge branch 'release/1.1.0'': 1.1.0 with commit count source 3dd090ad5f5cdc406c4afe3b13dba4e26d641f7a | 1.1.0}
    [2]: {Git tag '1.0.0': 1.0.0 with commit count source 1d54558c0c51d19286b908749c3f20ed9cf454a8 | 1.1.0}
    [3]: {Git tag 'v1.1.0': 1.1.0 with commit count source 2e7a6e89e58423a1678e651c062555fcd6847174 | 1.2.0}
    [4]: {Git tag '1.0.0': 1.0.0 with commit count source 1d54558c0c51d19286b908749c3f20ed9cf454a8 | 1.1.0}

• Each candidate should be interpreted as {Strategy type with commit count source | IncrementedVersion}. So this means that
  [3] was calculated using the TaggedCommitVersionStrategy with the commit count source being 2e7a6e8 and the incremented version would be 1.2.0.
• If PreventIncrementOfMergedBranchVersion was not set to true, the IncrementedVersion of [1] would have been 1.2.0 as well. This line of code disallows the version increment of [1].
• Due to this, [3] is the only candidate selected here.
• The CommitsSinceVersionSource for the selected base version is calculated here with baseVersionSource being 2e7a6e8 and currentCommit being fe0c9f2. Please refer to the Commit Graph above.
• GetCommitLog returns the following commit log (please refer to Commit Graph to verify the commits returned):

[2]	fe0c9f2 Merge branch 'release/1.1.0'	LibGit2Sharp.Commit
[1]	9443ab2 Test Commit for file '7059d6d4-dfb8-4fea-bac0-aa4858867ff2' -	LibGit2Sharp.Commit
[0]	ad246ca Test Commit for file '1fbd1f78-7453-488d-b0b8-0ea3c53ef48f' -	LibGit2Sharp.Commit

• The count, i.e. 3, of the returned commit log above is used as the CommitsSinceVersionSource causing the observed decrease and a deviation from the expected value of 6.
• Please note that the commits on the release branch are completely ignored in the commit log extraction.
• Also, had PreventIncrementOfMergedBranchVersion been set to false for develop, [1] would have been selected and with its version source(3dd090a) the CommitsSinceVersionSource would have been as expected, i.e. 6

2. Open questions:

2.1) Is GetCommitLog doing the right thing for the scenario mentioned above?
2.2) Should we just avoid setting PreventIncrementOfMergedBranchVersion, atleast for develop, update the unit test and the documentation in order to close this PR?

@asbjornu Could you please have a look?

[asbjornu]

Thanks for digging into this, @ruhullahshah! 🙏🏼

2.1) Is GetCommitLog doing the right thing for the scenario mentioned above?

I don't think that looks correct, no. The commits from the release branch should definitely be in there, imho.

2.2) Should we just avoid setting PreventIncrementOfMergedBranchVersion, atleast for develop, update the unit test and the documentation in order to close this PR?

Which consequences does that have? I assume that will break other tests?

[ruhullahshah]

@asbjornu You are welcome.

Here are my further findings:

1. Upon giving it more thought, I think GetCommitLog is doing the right thing with the input passed to it, i.e. with a baseVersionSource of 2e7a6e8 and currentCommit being fe0c9f2, the commit filter should return 3 commits if one looks up the field documentation provided by LibGit2Sharp.
2. Another question that should be answered is, if the version source of the TaggedCommitVersionStrategy is correct or not? In my opinion, it is correct because a tagged commit is a version source.
3. I have updated the documentation for prevent-increment-of-merged-branch-version and also updated the unit test to illustrate the behavior of GitVersion in this scenario.

Conclusion:

I do not think any code changes are necessary, the behavior should be documented (done already) and a unit test documenting this behavior should be added (done already)

[ruhullahshah]

@asbjornu Sorry, missed to answer this:

Which consequences does that have? I assume that will break other tests?

The consequences of setting prevent-increment-of-merged-branch-version to false for develop are that we give the version sources provided by the MergeMessageBaseVersionStrategy a chance as well and that, as exhibited by the updated unit test, yields the expected correct CommitsSinceVersionSource and no other unit tests break as there are no code changes.

[asbjornu]

Perfect! Great work, @ruhullahshah!

[ruhullahshah]

@asbjornu Thanks. I think in a Gitflow-based setting, we might also need to check the implications of merging a hotfix/major.minor.patch to develop with prevent-increment-of-merged-branch-version set to false. Concretely, if we have hotfix/1.0.1, but I still want develop to build 1.1.0 after it gets merged to develop

I will investigate this and we could merge these changes afterwards.

[asbjornu]

@asbjornu Thanks. I think in a Gitflow-based setting, we might also need to check the implications of merging a hotfix/major.minor.patch to develop with prevent-increment-of-merged-branch-version set to false. Concretely, if we have hotfix/1.0.1, but I still want develop to build 1.1.0 after it gets merged to develop

Indeed, a test for that would be nice.

I will investigate this and we could merge these changes afterwards.

Since the build is failing due to what seems to be AzDO outage, please feel free to add to this PR.

[ruhullahshah]

@asbjornu I have validated that setting prevent-increment-of-merged-branch-version to false for develop does not cause problems while merging a versioned hotfix into develop and added a test case for the same.

[asbjornu]

Thank you so much for your contributions, @ruhullahshah! ❤️ 🙏🏼

[ruhullahshah]

You are welcome @asbjornu