You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When getting the changes from the develop branch on top of an existing release branch, the commit counting of develop drops as the Merge Base commit changes.
Expected Behavior
The commit counting on develop should never drop, otherwise this generates overlapping build numbers.
Actual Behavior
[Test]publicvoidMergingDevelopToReleaseBranchShouldNotResetCommitCounterOfDevelop(){usingvarfixture=newEmptyRepositoryFixture();fixture.MakeATaggedCommit("2.0.0");fixture.BranchTo("release/3.0.0");fixture.BranchTo("develop");fixture.Repository.MakeCommits(8);// on developfixture.AssertFullSemver("3.1.0-alpha.8");// work on a beta releasefixture.Checkout("release/3.0.0");fixture.Repository.MakeCommits(20);fixture.AssertFullSemver("3.0.0-beta.1+20");// Finalize betafixture.ApplyTag("3.0.0-beta.1");fixture.AssertFullSemver("3.0.0-beta.1");// and start new onefixture.Repository.MakeCommits(2);// Counting commits from MergeBase of develop and release/3.0.0// counting from the 3.0.0-beta.1 would be better, but this is still okfixture.AssertFullSemver("3.0.0-beta.2+22");// 3.0.0-beta.2+2 would be better// we now want to get the changes from develop onto release/3.0.0 for the 2nd betafixture.MergeNoFF("develop");fixture.AssertFullSemver("3.0.0-beta.2+23");// Ok cool// ok, let's look at developfixture.Checkout("develop");// eh, wait what? Why has the version jumped back from 3.1.0 to 2.1.0?!!fixture.AssertFullSemver("2.1.0-alpha.8");// eh, ok, an extra commit should fix thatfixture.MakeACommit();// what?! Why do we reset back to alpha.1?! This will collide with a previous versions!!!fixture.AssertFullSemver("3.1.0-alpha.1");// expecting 3.1.0-alpha.9}
Workaround
[Test]publicvoidWorkaroundThisBehaviorByUsingDifferentVersions(){usingvarfixture=newEmptyRepositoryFixture();fixture.MakeATaggedCommit("2.0.0");fixture.BranchTo("master");fixture.BranchTo("release/3.0.0");fixture.BranchTo("develop");fixture.Repository.MakeCommits(8);// on developfixture.AssertFullSemver("3.1.0-alpha.8");// work on a beta releasefixture.Checkout("release/3.0.0");fixture.Repository.MakeCommits(20);fixture.AssertFullSemver("3.0.0-beta.1+20");// finalize the 3.0.0 betafixture.Checkout("develop");fixture.MergeNoFF("release/3.0.0");fixture.Repository.Branches.Remove("release/3.0.0");fixture.AssertFullSemver("3.1.0-alpha.29");// start the 3.0.1 betafixture.BranchTo("release/3.0.1");fixture.Repository.MakeCommits(10);fixture.AssertFullSemver("3.0.1-beta.1+10");// finalize the 3.0.1 beta and release itfixture.Checkout("develop");fixture.MergeNoFF("release/3.0.1");fixture.Repository.Branches.Remove("release/3.0.1");fixture.AssertFullSemver("3.1.0-alpha.40");fixture.Checkout("master");fixture.MergeNoFF("develop");fixture.AssertFullSemver("3.0.1+12");}
Context
Creating a beta tag (e.g. 3.0.0-beta.1) is then only useful if the develop and the release branches are completely independent.
I'm not sure how we could implement a fix for this. Finding the base commit from which the metadata value is currently calculated using the vanilla MergeBase functionality of git, which finds the shortest intersection of 2 branches.
Any ideas?
The text was updated successfully, but these errors were encountered:
franknarf8
changed the title
[Bug]
Merging develop to release branch makes alpha version jump back
Jul 19, 2022
franknarf8
changed the title
Merging develop to release branch makes alpha version jump back
[Bug] Merging develop to release branch makes alpha version jump back
Jul 20, 2022
Describe the bug
Hello again dear GitVersion maintainers :)
When getting the changes from the
develop
branch on top of an existingrelease
branch, the commit counting ofdevelop
drops as the Merge Base commit changes.Expected Behavior
The commit counting on
develop
should never drop, otherwise this generates overlapping build numbers.Actual Behavior
Workaround
Context
Creating a beta tag (e.g.
3.0.0-beta.1
) is then only useful if thedevelop
and therelease
branches are completely independent.I'm not sure how we could implement a fix for this. Finding the base commit from which the metadata value is currently calculated using the vanilla MergeBase functionality of git, which finds the shortest intersection of 2 branches.
Any ideas?
The text was updated successfully, but these errors were encountered: