This project is read-only.

Continuous Integration support for nuget packages?

Feb 4, 2013 at 8:08 AM

I'm missing the feature like the BuildNumberPrefix for assembly versioning which can be used in different builds (CI, Daily, ...) to prevent version conflicts and to have common VersionSeed.xml file for all that builds.

I would like to have BuildNumberPrefix working also for nuget packages or to figure out different approach. I'm not able to find the source code for the v2.0 release to add this support.

SemVer for nuget packages requires to have zero based version number resets, e.g. when you increment Minor part you have to reset Pach part to zero.

Ideally it would be nice if I could have one version definition for all builds and have automatic numbering support for CI builds, so that I have not to maintain two versions:
  1. one for release version (Manual Build definition) - e.g. 1.2.0 (which is manually incremented)
  2. another for CI version (CI Build definition) - e.g. 1.2.0.B (which is manually incremented)
As you can see, with the current version of tfsnugetter and tfsversioning activities I'm not able to achieve single maintenance of version for the same package from different builds.

Yours sincerely
Miroslav Galajda
Feb 6, 2013 at 2:45 PM
Apparently I didn't realize that BuildNumberPrefix was desired within NuGetter. The feature has been there the whole time (a carryover of common code between NuGetter and TfsVersioning) but a parameter was never included within the build template (there's a line of XAML code in the "BuildNumberPrefix" discussion topic showing how to add it in the current templates). I am adding that parameter into the templates for your use. I will post an update shortly. I need to create a few tests to verify that it is working as expected. It should but since there's a difference with NuGetter allowing semantic versioning, there could be a conflict when semantic versioning is done along with the build number prefix.

Feb 6, 2013 at 9:29 PM
Hello, thank you.

The semantic versioning rules should be OK with BuildNumber if I use it only for integration builds which would be in separate repository.
I'm following the guidelines from article at Top 10 NuGet (Anti-) Patterns.

I'm going to use separate repository for CI builds where I can put packages with autoincremented version with the buildnumber at the 4th part.
But the problem I have is that how to manage the desired version for production and for CI builds on one place?

Yours sincerely
Miroslav Galajda
Feb 6, 2013 at 9:34 PM
What I meant about a potential semantic versioning issue is within NuGetter. I just want to make sure that the right version number comes out of the version pattern processing since semantic versioning is a combination of strings and numbers. I don't want there to be any numeric errors when the build prefix is applied.

Feb 7, 2013 at 4:43 AM
Version 2.1 was released and includes build number prefix.

Feb 11, 2013 at 8:21 AM
Hello Mark,

thank you for your release.

What about achieving this approach:
  1. to have one common part of version definition for all build defintions in VersionInfo.xml
  2. and to have the specific part of version for specific build definitions, e.g. the Continuous Integration Build.
I would like to apply the semantic versioning rules, like one that says that you have to reset right part of version when you increment the left one and at the same time to have the ability to distinguish and manage all the build definitions for one place.
For example:
  1. Let have planned release version 1.2.0 (current version might be for example 1.1.9)
  2. Before the 1.2.0 is released you can work with prerelease pattern, lets say 1.2.0-alfa01, -alfa02, ...
  3. While you are working on the release you have CI builds where you have to set the version to be higher that the actual release/prerelease version.
    One of the ways you can do that is to set version to 1.2.0.B (B - build number) which will evaluate this version as the higher than any release/prerelease version.
    The build number prefix I would use for the packages build in integration builds, e.g. CI and Daily builds.
What do you suggests?
Does someone have the same requirements like me? It's the common requirement for the right nuget package semantic versioning, isn't it?

Thank you

Yours sincerely
Miroslav Galajda
Feb 14, 2013 at 1:05 AM

I am considering this but it will take some thought. It could be a relatively complicated change to the existing solution.

I appreciate your description, thanks!