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=new EmptyRepositoryFixture();
fixture.MakeATaggedCommit("2.0.0");
fixture.BranchTo("release/3.0.0");
fixture.BranchTo("develop");
fixture.Repository.MakeCommits(8);// on develop
fixture.AssertFullSemver("3.1.0-alpha.8");// work on a beta release
fixture.Checkout("release/3.0.0");
fixture.Repository.MakeCommits(20);
fixture.AssertFullSemver("3.0.0-beta.1+20");// Finalize beta
fixture.ApplyTag("3.0.0-beta.1");
fixture.AssertFullSemver("3.0.0-beta.1");// and start new one
fixture.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 ok
fixture.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 beta
fixture.MergeNoFF("develop");
fixture.AssertFullSemver("3.0.0-beta.2+23");// Ok cool// ok, let's look at develop
fixture.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 that
fixture.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=new EmptyRepositoryFixture();
fixture.MakeATaggedCommit("2.0.0");
fixture.BranchTo("master");
fixture.BranchTo("release/3.0.0");
fixture.BranchTo("develop");
fixture.Repository.MakeCommits(8);// on develop
fixture.AssertFullSemver("3.1.0-alpha.8");// work on a beta release
fixture.Checkout("release/3.0.0");
fixture.Repository.MakeCommits(20);
fixture.AssertFullSemver("3.0.0-beta.1+20");// finalize the 3.0.0 beta
fixture.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 beta
fixture.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 it
fixture.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: