Version string for both stable and pre-release NuGet builds

[asbjornu]

I don't think GitVersion supports this scenario, so I'll just describe it and hope someone can point me in the right direction if this is already possible. If not, this can be considered a feature request.

I'd love to have a single build configuration across all branches of a project that ends up in a NuGet package. Stable releases should only be built from master and have AssemblyInformationalVersion and NuGet version set to:

• {major}.{minor}.{patch}.{buildmetadata}

All other branches (development, feature branches, etc.) should have AssemblyInformationalVersion and NuGet version set to:

• {major}.{minor}.{patch}.{buildmetadata}-{branchname}

The -{branchname} part will ensure that NuGet treats the package as a prerelease. This conditional switching on whether the -{branchname} part should be included (which it shouldn't on master builds), makes it difficult to just pass a variable to the "NuGet Pack" build step or have it use AssemblyInformationalVersion.

It seems like I should be able to use the system.GitVersion.NuGetVersion variable, but it seems to lack both {buildmetadata} and {branchname} (for both master and feature branches), so that won't work. system.GitVersion.InformationalVersion won't work either, since it contains {fullbuildmetadata} for both master and feature branch builds (which would cause master branch builds to end up as prerelease packages in NuGet).

So, I'm wondering if the variable I'm after exists. If it doesn't, I'd highly appreciate if it was added.

[asbjornu]

From the GitVersion tests, it seems like both GitVersion.NuGetVersion and GitVersion.NuGetVersionV2 should contain what I want, but from the builds I've done, this is what those (and a couple of other variables for completeness) contain on master:

• NuGetVersionV2: 2.7.15
• NuGetVersion: 2.7.15
• ClassicVersionWithTag: 2.7.15.1
• InformationalVersion: 2.7.15+1.Branch.master.Sha.29a154a9a13a14b680ba4bec39132a7010509995

And on the branch structuremap3:

• NuGetVersionV2: 2.7.15
• NuGetVersion: 2.7.15
• ClassicVersionWithTag: 2.7.15.67
• InformationalVersion: 2.7.15+67.Branch.structuremap3.Sha.d70fef545bbaecbc3fdc3759e1f9ff802449258b

Shouldn't at least one of the variables on the structuremap3 build contain -structuremap3? I'm also surprised that the version number is 2.7.15, since the last tag in the repository is 2.7.14. Isn't it natural that GitVersion increments {buildmetadata} and not {patch}?

[gep13]

@asbjornu I have just ran GitVersion on one of my repositories, and this is what I get:

{
  "Major":0,
  "Minor":2,
  "Patch":0,
  "PreReleaseTag":"ProblemWithUpdate",
  "PreReleaseTagWithDash":"-ProblemWithUpdate",
  "BuildMetaData":4,
  "FullBuildMetaData":"4.Branch.ProblemWithUpdate.Sha.f966d8ba402bd6b50ba6efa3b98787ab2b28c012",
  "MajorMinorPatch":"0.2.0",
  "SemVer":"0.2.0-ProblemWithUpdate",
  "LegacySemVer":"0.2.0-ProblemWithUpdate",
  "LegacySemVerPadded":"0.2.0-ProblemWithUpdate",
  "AssemblySemVer":"0.2.0.0",
  "FullSemVer":"0.2.0-ProblemWithUpdate+4",
  "InformationalVersion":"0.2.0-ProblemWithUpdate+4.Branch.ProblemWithUpdate.Sha.f966d8ba402bd6b50ba6efa3b98787ab2b28c012",
  "ClassicVersion":"0.2.0.4",
  "ClassicVersionWithTag":"0.2.0.4-ProblemWithUpdate",
  "BranchName":"ProblemWithUpdate",
  "Sha":"f966d8ba402bd6b50ba6efa3b98787ab2b28c012",
  "AssemblyVersion":"0.2.0.0",
  "AssemblyFileVersion":"0.2.0.0",
  "OriginalRelease":"f966d8ba402bd6b50ba6efa3b98787ab2b28c012.2014-10-24 18:54:14Z",
  "NuGetVersionV2":"0.2.0-problemwithupdate",
  "NuGetVersion":"0.2.0-problemwithupdate"
}

Isn't the "PreReleaseTagWithDash" one of the things that you are looking for? My branch name is ProblemWithUpdate

With regard to the version number, what is your branching structure like? Have you seen these:

https://github.com/Particular/GitVersion/wiki/GitFlowExamples
https://github.com/Particular/GitVersion/wiki/GitHubFlowExamples

The only way that the Patch version is updated is if you create a hotfix branch. The buildmetadata is incremented for each commit into the repository.

[asbjornu]

@gep13 What's the last tag in your repository?

Besides naming our development branch development and not develop, we follow GitFlow with master, development and feature branches, with merging from the latter to the former.

When the last tag in the repository is 2.7.14, I thought the versioning scheme for the different branches should be like this:

master

• ClassicVersionWithTag: 2.7.14.12
  • The major, minor and patch version is identical to the last tag.
  • The buildmetadata has been increased to 12, as the number of commits since the last tag.
  • There's no -master suffix

development

• ClassicVersionWithTag: 2.7.15.63-development
  • The major and minor version is identical to the last tag.
  • The patch has been incremented by 1 to ensure a higher version number than the last stable release.
  • The buildmetadata has been increased to 63, as the number of commits since the last tag.
  • A -development suffix has been appended to indicate that it's a prerelease.

feature-3

• ClassicVersionWithTag: 2.7.15.104-feature-3
  • The major and minor version is identical to the last tag.
  • The patch has been incremented by 1 to ensure a higher version number than the last stable release.
  • The buildmetadata has been increased to 104, as the number of commits since the last tag.
  • A -feature-3 suffix has been appended to indicate that it's a prerelease.

I expect the master branch to stay on the same major, minor and patch version as the last tag, but to automatically increment the buildmetadata part. I expect development and feature branches to have the same major and minor version as the last tag, but have their patch and buildmetadata parts incremented as well as the branch name suffixed.

Are these expectations wrong? If they are, is there anything I can do to configure GitVersion to work more in the way I want?

[asbjornu]

The problem might be that we don't exactly follow GitFlow or GitHubFlow. We don't do release branches or hotfix branches, we only do feature, develop and master branches. Is it possible to get our git scheme to work with GitVersion in any way, for example by letting GitVersion.exe know through parameters what our scheme looks like?

[asbjornu]

I've now tried to adopt git-flow in SharpRaven, but related to the problems I've described in this issue, I'm now having problems with having tagged and published version 1.4.2 on NuGet and then builds from the "develop" branch being versioned as 1.5.0-unstableX.

The problem with this is that every time I tag a new revision, the Xx` will be reset, since it's now only X number of commits since the last tag. So if you look at the prerelease versions of SharpRaven published on NuGet, it looks like this:

1. 2014-11-13: 1.5.0-unstable0007
2. 2014-11-14: 1.4.1
3. 2014-11-14: 1.5.0-unstable0012
4. 2014-11-17: 1.5.0-unstable0027
5. 2014-12-17: 1.5.0-unstable0009
6. 2014-12-17: 1.5.0-unstable0011

As you can see, the version number on the unstable package suddenly regresses from 0027 to 0009, which won't make the latest published package available as the latest version, since its version number is less than an older one.

If GitVersion had incremented the revision instead of the minor version part for "develop" builds, it would have worked much better. What I'd like is to have builds from "develop" versioned as 1.4.3-unstableX when the latest tag is 1.4.2. Is this at all possible, @JakeGinnivan, @gep13?

[JakeGinnivan]

// @andreasohlund @SimonCropp @nulltoken

I don't use GitFlow so not really sure about this side of things

[asbjornu]

@JakeGinnivan Ok, but regardless of flow-type, what should the version number in the "develop" branch be when the last tag is 1.4.2?