[Bug] SemVer of a feature branch started from a release branch gets decremented

Describe the bug

Hello! We are using GitVersion with the GitFlow branching scheme. I'd expect that the feature branch started from a release branch has the same SemVer as the parent release branch.

Expected Behavior

SemVer of a commit on a feature branch is the same as the SemVer of a parent release branch.

Actual Behavior

SemVer gets decremented to the previous release version.

Steps to Reproduce

[Test]
public void ShouldPickUpReleaseVersionAfterCreatedFromRelease()
{
    using var fixture = new EmptyRepositoryFixture();

    // Create develop and a release branch
    fixture.MakeATaggedCommit("1.0.0");
    fixture.MakeACommit();
    fixture.BranchTo("develop");
    fixture.BranchTo("release/1.1.0");
    fixture.MakeACommit();
    fixture.AssertFullSemver("1.1.0-beta.1+1");


    // Create a feature branch from the release/1.1.0 branch
    fixture.BranchTo("feature/test");
    fixture.MakeACommit();
    fixture.AssertFullSemver("1.1.0-test.1+1");  // this fails (returns 1.0.0-test.1+3)
}

Context

I know this can be fixed by setting tracks-release-branches: true for the release branch type, but this has other consequences as well - for example if a release/2.0.0 branch is started in the same repo, the SemVer of a build from a feature branch will be 2.0.0 even if its parent branch is release/1.1.0.

Also looking at the docs for track-release-branches - Indicates this branch config represents develop in GitFlow. - I am wary to change it for release branches.

It looks as it should be the default behaviour for me, but am I missing some other configuration options that would change this?

Your Environment

Version Used: The unit test above was tested with main at 5.10.4-beta.1+41.Branch.main.Sha.68604754376c7df1d7a378a3a29fb92d55dd3013, same behavior is observed in our CI where 5.8.2 is installed
Operating System and version: Mac11 locally, Windows 10 in CI

feature/* branches should be created from develop, not from a release/* branch. If you change that, I think you'll get more of the inteded behaviour.

So the idea is that stabilizing a release/* branch should be done by direct pushes?

Yes, or by merging more feature/* branches into develop and then rebasing the release/* branch on develop or merging develop into the release/* branch.

Could this be considered a future improvement? It is not explicitly stated how bugfixes should be done on release/* branches in GitFlow, but having the ability to go through a PR with doing such a fix would be nice. Merging develop into release/* is not always an option, as more development could have already happened there.

@ni-jsuchocki

It not rare to have rules on projects that only allow changes through pull requests. Especially on release branches as they tend to generate releasable artifacts.

Also, as @ni-jsuchocki said, if a team is big enough, it is also common to have new development on develop while stabilization work is happening on the release branch. So we might not want the new changes from develop while stabilizing the release branch.

Sure, I understand that. But I don't see a way to tell GitVersion to have feature/* branches both track develop and release/* branches simultaneously. At least not without a pull request that walks the commit tree until it finds a release/* branch and then somehow decides that "yes, this is where I'm going to derive my version number from".

An alternative would be to name the release-stabilizing branches differently from feature/* and configure those to track release/* somehow. I've never done that myself, so I'm not sure whether it's going to work, but it's worth trying.

Please see the discussion in #3101.

Create integration test for [Bug] GitTools#3151 and make some minor c…

Please take a look and tell me if you are agree with this test (see integration test here). Two commits have been pushed after you entered the beta phase that's why +2 IMO

@HHobeck

Hi @HHobeck, sorry for not reaching out earlier but thanks a lot for the changes you've done here! I finally found some time to play around with the current state of the code and your changes seem to really improve on a couple of issues we were encountering earlier! Can't wait for the 6.0 release :)

🎉 This issue has been resolved in version 6.0.0 🎉
The release is available on:

Your GitReleaseManager bot 📦🚀

Navigation Menu

Repository navigation

[Bug] SemVer of a feature branch started from a release branch gets decremented #3151

Expected Behavior

Actual Behavior

Steps to Reproduce

Context

Your Environment

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Bug] SemVer of a feature branch started from a release branch gets decremented #3151

Description

Expected Behavior

Actual Behavior

Steps to Reproduce

Context

Your Environment

Activity

asbjornu commented on Aug 27, 2022

ni-jsuchocki commented on Aug 29, 2022

asbjornu commented on Aug 29, 2022

ni-jsuchocki commented on Aug 31, 2022

ni-fgenois commented on Aug 31, 2022

asbjornu commented on Sep 1, 2022

asbjornu commented on Sep 2, 2022

HHobeck commented on Sep 16, 2022

ni-jsuchocki commented on Dec 16, 2022

arturcic commented on Dec 22, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions