GitVersion icon indicating copy to clipboard operation
GitVersion copied to clipboard

[Bug] Wrong version from the release branche

Open mouradchama opened this issue 4 years ago • 4 comments

Describe the bug Hi,

I'm trying the get the right version on my release branch, the release name doesn't respect the pattern used to retrieve the version, my branch name is release/R2112.

gitVersion.yml content:

next-version: 2.0
branches:
  develop:
    tag: beta
  release:
    tag: rc
  hotfix:
    tag: rc

I've already released a version on production: master: tag 2.0.0 develop: the generated versions are 2.1.0-beta.x (which is fine for me)

If I create the release with the name release/2.1.0 the generated version will be 2.1.0-rc.x if I create the release with the name release/R2112 the generated version will be 2.0.0-rc.x

Expected Behavior

The generated version should be 2.1.0-rc.x

Actual Behavior

The generated version is 2.0.0-rc.x

Context

Your Environment

  • Version Used: 5.8.1

Thank you in advance.

mouradchama avatar Nov 26 '21 16:11 mouradchama

First remove next-version: 2.0. If that has no effect, then great; less configuration. If it doesn't help increment the release branch to 2.1 then try to configure increment: Minor and track-merge-target: true on release.

branches:
  develop:
    tag: beta
  release:
    tag: rc
    increment: Minor
    track-merge-target: true
  hotfix:
    tag: rc

asbjornu avatar Nov 29 '21 11:11 asbjornu

I have the same issue. We use Jira and Bitbucket to create the branches, thus they have ticket names in the branch names. The following release branch release/ICO-5-release-v1.1.0 is producing 5.0.0-beta.1. Only msbuild package is producing wrong versions, the global tool is doing it correctly.

Ksdmg avatar Jan 13 '22 13:01 Ksdmg

It sounds like you have a different problem, @Ksdmg. release/ICO-5-release-v1.1.0 producing the version number 5.0.0-beta.1 sounds like an unintended match on the 5 in ICO-5 and not related to the version calculation logic. You can see the release branch parsing logic here:

https://github.com/GitTools/GitVersion/blob/debc84f377d463aa7e5b638d3fbe7a1b665c6911/src/GitVersion.Core/VersionCalculation/BaseVersionCalculators/VersionInBranchNameVersionStrategy.cs#L43-L55

I would thus advise you against having numbers in release branches that are not supposed to produce a version number.

asbjornu avatar Jan 13 '22 14:01 asbjornu

Just to understand your scenario: You expecting that GitVersion detects the version 2.1.0 from the release branch with the name release/R2112?

HHobeck avatar Sep 21 '22 18:09 HHobeck

I have taken a look into it. In your scenario the version increment strategy is set to Increment.None for release branches. That means if you not providing the version number within the branch name it yields to 2.0.0-beta.1+2.

If you want to always increment by minor please do the following configuration change:

[Test]
public void Just_A_Test()
{
    var configuration = GitFlowConfigurationBuilder.New
        .WithBranch("release", _ => _
            .WithIsReleaseBranch(false)
            .WithIncrement(IncrementStrategy.Minor)
        ).Build();

    using var fixture = new EmptyRepositoryFixture("main");
    fixture.MakeATaggedCommit("2.0.0");

    fixture.BranchTo("develop");
    fixture.MakeACommit("1");

    // ✅ succeeds as expected
    fixture.AssertFullSemver("2.1.0-alpha.1", configuration);

    fixture.BranchTo("release/R1234");
    fixture.MakeACommit("2");

    // ✅ succeeds as expected
    fixture.AssertFullSemver("2.1.0-beta.1+2", configuration);
}

HHobeck avatar Jun 05 '23 05:06 HHobeck