Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
ni-jsuchocki opened this issue Jul 12, 2022 · 10 comments · Fixed by #3190
Closed

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

ni-jsuchocki opened this issue Jul 12, 2022 · 10 comments · Fixed by #3190
Labels
Milestone

Comments

@ni-jsuchocki
Copy link
Contributor

ni-jsuchocki commented Jul 12, 2022

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
@ni-jsuchocki ni-jsuchocki changed the title [Bug] [Bug] SemVer of a feature branch started from a release branch gets decremented Jul 12, 2022
@asbjornu
Copy link
Member

asbjornu commented Aug 27, 2022

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
Copy link
Contributor Author

ni-jsuchocki commented Aug 29, 2022

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

@asbjornu
Copy link
Member

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
Copy link
Contributor Author

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
Copy link
Contributor

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
Copy link
Member

asbjornu commented Sep 1, 2022

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
Copy link
Member

asbjornu commented Sep 2, 2022

Please see the discussion in #3101.

@HHobeck
Copy link
Contributor

HHobeck commented Sep 16, 2022

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

@asbjornu asbjornu added this to the 6.x milestone Oct 11, 2022
@ni-jsuchocki
Copy link
Contributor Author

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 :)

@arturcic arturcic modified the milestones: 6.x, 6.0.0-alpha.1 Dec 22, 2022
@arturcic
Copy link
Member

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

Your GitReleaseManager bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
5 participants