Add support for nuget special version limitations

[arledesma]

Nuget Special Version does not support strings longer than 20 characters. In order to optimize continuous delivery, based off of ticket numbers as feature branches (e.g. feature-TKT-9999), we can label a nuget package with the version including the ticket number (e.g. 1.2.3-TKT-9999) for end to end testing of new features that are maintained in a dependent nuget package.

• Adds NugetPackageVersion
• Adds tests and updates existing tests to support new variable

[JakeGinnivan]

Not sure this should have the build metadata?

[JakeGinnivan]

Thanks for the pull request, the LegacySemVer and LegacyPaddedSemVer are there for NuGet compatibility (and any other tool which has crap SemVer support).

Personally I think you should just update the logic of the LegacySemVer to make sure it doesn't generate a pre-release tag longer than 20 characters.

The SemanticVersion class should have no idea about branches etc. The logic which removes feature/hotfix/release from the tag should be moved to outside the SemanticVersion class

[arledesma]

@JakeGinnivan I agree that SemanticVersion should not have any idea about branches, but was unable to determine a good method in order to implement this without some major refactoring. The purpose of the pull request was, indeed, to get some of the branch information into the version while keeping the special version under 20 characters. Having a feature name in the version allows for continuous deployment to easily tie up a deployable package to a specific feature -- in our case using octopus deploy. The version provided by LegacySemVer does not quite get us the information that is required for this purpose.

e.g. Both of these branches produce the same 1.1.0-unstable0 version. If required, we can cobble together a version via MajorMinorPatch- BranchName, and trim it up, but this feature seems to me to be something that others could find value in.

PS S:\GitHub\GitVersion\GitVersionExe> .\bin\Release\GitVersion.exe { "Major":1, "Minor":1, "Patch":0, "PreReleaseTag":"unstable.0", "PreReleaseTagWithDash":"-unstable.0", "BuildMetaData":98, "FullBuildMetaData":"98.Branch.feature/AddNugetSpecialVersionSupport.Sha.50b88c11f632f7be1b2d64fb83d7e6a4545dd459", "MajorMinorPatch":"1.1.0", "SemVer":"1.1.0-unstable.0", "LegacySemVer":"1.1.0-unstable0", "LegacySemVerPadded":"1.1.0-unstable0000", "AssemblySemVer":"1.1.0.0", "FullSemVer":"1.1.0-unstable.0+98", "InformationalVersion":"1.1.0-unstable.0+98.Branch.feature/AddNugetSpecialVersionSupport.Sha.50b88c11f632f7be1b2d64fb83d7e6a4545dd459", "ClassicVersion":"1.1.0.98", "ClassicVersionWithTag":"1.1.0.98-unstable.0", "BranchName":"feature/AddNugetSpecialVersionSupport", "Sha":"50b88c11f632f7be1b2d64fb83d7e6a4545dd459", "AssemblyVersion":"1.1.0.0", "AssemblyFileVersion":"1.1.0.0", "OriginalRelease":"50b88c11f632f7be1b2d64fb83d7e6a4545dd459.2014-06-03 01:29:29Z", "NugetPackageVersion":"1.1.0-AddNugetSpecialVersi" } PS S:\GitHub\GitVersion\GitVersionExe> 

PS S:\GitHub\GitVersion\GitVersionExe> .\bin\Release\GitVersion.exe { "Major":1, "Minor":1, "Patch":0, "PreReleaseTag":"unstable.0", "PreReleaseTagWithDash":"-unstable.0", "BuildMetaData":98, "FullBuildMetaData":"98.Branch.feature/AnotherFeature.Sha.50b88c11f632f7be1b2d64fb83d7e6a4545dd459", "MajorMinorPatch":"1.1.0", "SemVer":"1.1.0-unstable.0", "LegacySemVer":"1.1.0-unstable0", "LegacySemVerPadded":"1.1.0-unstable0000", "AssemblySemVer":"1.1.0.0", "FullSemVer":"1.1.0-unstable.0+98", "InformationalVersion":"1.1.0-unstable.0+98.Branch.feature/AnotherFeature.Sha.50b88c11f632f7be1b2d64fb83d7e6a4545dd459", "ClassicVersion":"1.1.0.98", "ClassicVersionWithTag":"1.1.0.98-unstable.0", "BranchName":"feature/AnotherFeature", "Sha":"50b88c11f632f7be1b2d64fb83d7e6a4545dd459", "AssemblyVersion":"1.1.0.0", "AssemblyFileVersion":"1.1.0.0", "OriginalRelease":"50b88c11f632f7be1b2d64fb83d7e6a4545dd459.2014-06-03 01:29:29Z", "NugetPackageVersion":"1.1.0-AnotherFeature" } PS S:\GitHub\GitVersion\GitVersionExe> 

[JakeGinnivan]

I think maybe the bug is that feature branches are not given the same love as pull request branches. Our workflow (including Particular as far as I understand) tends to be we build master, develop, release and pull requests. Feature branches are pretty much ignored.

I think what we need is that the feature branch finder should not use -unstable, instead it should use the part of the branch name after the first - or /. I also suggest maybe splitting on _ and just using the first part.
We have a similar naming method where we have feature/TKT-2134_JiraDescription.

From what you have said:

• You use a single repo, and push feature branches into that branch (no forks)
• You do not use pull requests?

Could you explain a bit more about your workflow and build server setup (in terms of what branches and ref's you monitor to build)

Thoughts @andreasohlund

[JakeGinnivan]

Also, the reason feature branches are ignored (in our workflows) is they are all created in forks, so the only way they are built are via pull requests

[andreasohlund]

Correct, at least for all TeamCity users since there is no way to build
pulls + feature branches without getting "double builds"

That's why we choose to not build feature branches since we want devs to
open pulls as soon as possible

On Wed, Jun 4, 2014 at 3:06 PM, Jake Ginnivan notifications@github.com
wrote:

Also, the reason feature branches are ignored is they are all created in
forks, so the only way they are built are via pull requests

—
Reply to this email directly or view it on GitHub
#184 (comment).

[arledesma]

@JakeGinnivan

• You use a single repo, and push feature branches into that branch (no forks)

This is mostly correct. We use github enterprise and contain our groups in teams within their own organizations. Everyone will typically work within the same repository and only use forks when going across organizations.

• You do not use pull requests?

We do use pull requests.

Our developers work from stories, which may be a part of an epic or theme, that encompass an entire vertical slice across our infrastructure. At times we may be limited to a single repository, but in the case of updating a library we may need to test a pre-release out prior to opening a pull request. As we sign everything, we can not actually build a library locally and promote the use of it outside of our build system (bamboo) due to the testing environment being a replica of production. As such, we have all of our repositories monitored for new branches and will have plan branches within bamboo created on the fly. Those plan branches will run through all tests and alert a developer if things are breaking continuously. What we can not do with this is test new features that are added into the library that will be exposed upstream (webapi, nservicebus, etc...). We will generally have a theme branch, and inside of that a feature branch that we will introduce the reference to the pre-release nuget package. Once initial testing is approved then we will move the library through regression testing, then promote to a release at which time we may open a pull request on the other feature branch into the parent feature branch (which is the theme/epic) for testing the entire theme/epic. We have multiple people working on different features within each of these libraries, so pull-request -> release candidate can get very messy while keeping the pre-releases tied specifically to a feature is fairly neat and easily automated.

[JakeGinnivan]

@arledesma I have put up another pull request (#189) which adds better feature branch support and improves the legacy versions to trim to max of 20 characters.

Could you have a look and see if it solves your problem?

[arledesma]

@JakeGinnivan #189 looks excellent.

Closing this.