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

[ni-jsuchocki]

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

[asbjornu]

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.

[ni-jsuchocki]

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

[asbjornu]

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

[ni-jsuchocki]

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-fgenois]

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.

[asbjornu]

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.

[asbjornu]

Please see the discussion in #3101.

[HHobeck]

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