Feature branch with GitHubFlowVersion doesn't append pre release tag

[MacDennis76]

I am testing version 2.0.0 of GitVersion, the command line version in combination with a GitHubFlow repository. This repo has a master branch and a number of feature branches.

The latest tag (on master) is equal to 1.6.0.

When working with feature branches the following is the result, in this example a feature branch called 'feature-test' is used:

{
"Major":1,
"Minor":6,
"Patch":1,
"PreReleaseTag":"",
"PreReleaseTagWithDash":"",
"BuildMetaData":9,
"FullBuildMetaData":"9.Branch.feature-test.Sha.747cf43601b10dd87508ba7d72a47c0e9321294b",
"MajorMinorPatch":"1.6.1",
"SemVer":"1.6.1",
"LegacySemVer":"1.6.1",
"LegacySemVerPadded":"1.6.1",
"AssemblySemVer":"1.6.1.0",
"AssemblyFileSemVer":"1.6.1.0",
"FullSemVer":"1.6.1+9",
"InformationalVersion":"1.6.1+9.Branch.feature-test.Sha.747cf43601b10dd87508ba7d72a47c0e9321294b",
"ClassicVersion":"1.6.1.9",
"ClassicVersionWithTag":"1.6.1.9",
"BranchName":"feature-test",
"Sha":"747cf43601b10dd87508ba7d72a47c0e9321294b",
"NuGetVersionV2":"1.6.1",
"NuGetVersion":"1.6.1"
}

Is this expected behaviour?
Because this is a pre release I would have expect a pre release tag?
This is without a NextVersion.txt file, when I add one with a version equal to '1.7.0' the following is the result:

{
"Major":1,
"Minor":7,
"Patch":0,
"PreReleaseTag":"",
"PreReleaseTagWithDash":"",
"BuildMetaData":11,
"FullBuildMetaData":"11.Branch.feature-test.Sha.bf90ef4e6e000dd876f47fae510052ddfae8c23d",
"MajorMinorPatch":"1.7.0",
"SemVer":"1.7.0",
"LegacySemVer":"1.7.0",
"LegacySemVerPadded":"1.7.0",
"AssemblySemVer":"1.7.0.0",
"AssemblyFileSemVer":"1.7.0.0",
"FullSemVer":"1.7.0+11",
"InformationalVersion":"1.7.0+11.Branch.feature-test.Sha.bf90ef4e6e000dd876f47fae510052ddfae8c23d",
"ClassicVersion":"1.7.0.11",
"ClassicVersionWithTag":"1.7.0.11",
"BranchName":"feature-test",
"Sha":"bf90ef4e6e000dd876f47fae510052ddfae8c23d",
"NuGetVersionV2":"1.7.0",
"NuGetVersion":"1.7.0"
}

My plan is to use GitVersion in combination with TeamCity and Octopus Deploy. Each feature should be deployable to a testing environment and this means that I would need to be able to also package (NuGet) and deploy pre releases (features).

So, very curious to know if this is normal behaviour.

[gep13]

@robdmoore do you think that this is related to your issue: #331

[robdmoore]

I think it's a duplicate, yeah.

[JakeGinnivan]

Different issue. #337 fixes it

[MacDennis76]

I tried the latest source which includes #337.

The result with a feature branch called feature/TOHISP-55

{
"Major":1,
"Minor":6,
"Patch":1,
"PreReleaseTag":"TOHISP-55",
"PreReleaseTagWithDash":"-TOHISP-55",
"BuildMetaData":2,
"FullBuildMetaData":"2.Branch.feature/TOHISP-55.Sha.9f5ccc8addd702da2b235b202f3acf562a7b297b",
"MajorMinorPatch":"1.6.1",
"SemVer":"1.6.1-TOHISP-55",
"LegacySemVer":"1.6.1-TOHISP55",
"LegacySemVerPadded":"1.6.1-TOHISP55",
"AssemblySemVer":"1.6.1.0",
"AssemblyFileSemVer":"1.6.1.0",
"FullSemVer":"1.6.1-TOHISP-55+2",
"InformationalVersion":"1.6.1-TOHISP-55+2.Branch.feature/TOHISP-55.Sha.9f5ccc8addd702da2b235b202f3acf562a7b297b",
"ClassicVersion":"1.6.1.2",
"ClassicVersionWithTag":"1.6.1.2-TOHISP-55",
"BranchName":"feature/TOHISP-55",
"Sha":"9f5ccc8addd702da2b235b202f3acf562a7b297b",
"NuGetVersionV2":"1.6.1-tohisp55",
"NuGetVersion":"1.6.1-tohisp55"
}

Looks good to me.

But, this is the result when you use a hyphen in a branch called feature-TOHISP-55 which is a valid name for a branch:

{
"Major":1,
"Minor":7,
"Patch":0,
"PreReleaseTag":"",
"PreReleaseTagWithDash":"",
"BuildMetaData":13,
"FullBuildMetaData":"13.Branch.feature-TOHISP-91.Sha.729e1b66f9adf293536860dc94a9272408de1004",
"MajorMinorPatch":"1.7.0",
"SemVer":"1.7.0",
"LegacySemVer":"1.7.0",
"LegacySemVerPadded":"1.7.0",
"AssemblySemVer":"1.7.0.0",
"AssemblyFileSemVer":"1.7.0.0",
"FullSemVer":"1.7.0+13",
"InformationalVersion":"1.7.0+13.Branch.feature-TOHISP-91.Sha.729e1b66f9adf293536860dc94a9272408de1004",
"ClassicVersion":"1.7.0.13",
"ClassicVersionWithTag":"1.7.0.13",
"BranchName":"feature-TOHISP-91",
"Sha":"729e1b66f9adf293536860dc94a9272408de1004",
"NuGetVersionV2":"1.7.0",
"NuGetVersion":"1.7.0"
}

The Stash repo has the following format:
https://stash/scm/customer/client-project.git

The following test fails:

    [Test]
    public void ShouldNotUseNumberInFeatureBranchAsPreReleaseNumberWithHyphen()
    {
        using (var fixture = new EmptyRepositoryFixture(new Config()))
        {
            fixture.Repository.MakeATaggedCommit("1.0.0");
            fixture.Repository.CreateBranch("feature-JIRA-123");
            fixture.Repository.Checkout("feature-JIRA-123");
            fixture.Repository.MakeCommits(5);

            fixture.AssertFullSemver("1.0.1-JIRA-123+5");
        }
    }

Result:

Created git repository at 'D:\web\GitVersion\GitVersionCore.Tests\bin\Release\TestRepositories\4d01858c-8426-4345-a995-9c85ca5f094e'
Running against branch: feature-JIRA-123
GitHubFlow version strategy will be used
Shouldly.ChuckedAWobbly :
fixture.AssertFullSemver("1.0.1-JIRA-123+5");
should be
"1.0.1-JIRA-123+5"
but was
"1.0.1-feature-JIRA-123+5"

[JakeGinnivan]

@MacDennis76 I am working on the Config based versioning branch and hit an issue.

The above now ends up being 1.0.1-JIRA-123.1+5. Notice the .1, I think that is correct.. What do you think?

[MacDennis76]

What would be the added benefit of .1 in this case?
I understand it's usage when dealing with release branches but not directly for short lived feature branches.

It would basically mean the first version of this feature. But how to bump it?

[JakeGinnivan]

If you release a package which is off a feature branch, it should be tagged. Once it is released the build should be producing a new version.

Without the .1 you can never release from a feature branch more than once.

[JakeGinnivan]

We would add a config property to allow skipping of the .1, but not sure that is right

[MacDennis76]

Clear, let's assume we want to release a feature branch more than once.
Then we get ..
1.0.1-JIRA-123.1+5
1.0.1-JIRA-123.2+7
1.0.1-JIRA-123.3+10
etc, right?

But we use Octopus Deploy for our deployments. Which relies on Nuget.
So, what would be the corresponding (unique) Nuget version numbers?

[JakeGinnivan]

I am working on #338 which makes this scenario a lot better.

There will be a config which switches the mode of GitVersion. There are two options, ContinuousDelivery and ContinuousDeployment. We currently are the first, where you tag each release and that causes a SemVer bump.

Continuous Deployment will bump the build metadata to be the 4th part version number. So you will get:

1.0.1.1-JIRA-123.1+1
1.0.1.2-JIRA-123.2+2
1.0.1.3-JIRA-123.3+3

Or something like that

[JakeGinnivan]

Actually. I think it is

1.0.1.1-JIRA-123+1
1.0.1.2-JIRA-123+2
1.0.1.3-JIRA-123+3

[orjan]

I think your first example is better since I don't think it's semver to add .buildnumber after the patch?

Sent from my iPhone

On 25 jan 2015, at 10:31, Jake Ginnivan notifications@github.com wrote:

Actually. I think it is

1.0.1.1-JIRA-123+1
1.0.1.2-JIRA-123+2
1.0.1.3-JIRA-123+3

—
Reply to this email directly or view it on GitHub.

[JakeGinnivan]

Both use the 4th part.

I am not sure how else to solve the issue. The problem is this:

If we bump the patch every commit and you commit 4 times. You then get 4 packages (say 1.0.1, 1.0.2, 1.0.3, 1.0.4). Then the 4th one you use Octopus to deploy. That means that the end deployed has gone from 1.0.0 to 1.0.4 in a single release.

Our commit counting is part of the build metadata which is not part of the SemVer.

I have actually looked at the code. For pre-release we change the number on the tag. i.e

1.0.1-JIRA-123.1+1
1.0.1-JIRA-123.2+2
1.0.1-JIRA-123.3+3

But for stable packages we append a 4th part.

1.0.1.1
1.0.1.2
1.0.1.3

Thoughts on other ways to solve?