Hello,

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

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.

Mark

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

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.

Mark

Version 2.1 was released and includes build number prefix.

Mark

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

Miroslav,

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!

Mark