This project is read-only.

Constant Incremental Versioning

Oct 19, 2011 at 5:17 PM


I've been using your custom versioning and really like it, especially the Assembly Attribute Replacement functionality with the seed file! I recently came across the resource below because I found myself in a similar situation where managers in TFS want to see version and not a datetime versioning pattern. I'm wondering what your thoughts are on this approach and if it is something you may consider incorporating into your Work Flow?




Oct 20, 2011 at 4:54 AM
Edited Oct 20, 2011 at 1:47 PM

Hey Jared,

I really appreciate the kind comments.  Much thanks!

As for the versioning you refer to, if you just want an incremental versioning scheme based on the build number (total builds over time), then you can absolutely do that now.  The build number (as part of the build number format a.k.a "$(Rev:.r)") increments as long as the rest of the resulting build number format name does not change.  The default value when you create a build definition includes the date and when that value changes at midnight, the build number will reset back to 1.  If you remove the date portion, the build number will continue to increment forever.

So, to do what (I believe) you're asking for, change the build number format to a constant value but still include "$(Rev:.r)" at the end and in your seed file version pattern use something like this: "1.1.b.0".  Then, for example, the 67th build would give you a version number of "" (no date components).

If this isn't what you are asking for, please let me know.  I definitely want to know if there are ways to make this component better/more useful.




Mar 21, 2012 at 9:43 PM

Yes it would be great if you could modify the Build Number Format to allow a parameter for the Assembly File Version, so we could have something like:

$(BuildDefinitionName)_$(AssemblyFileVersion or AssemblyVersion)_$(Dateyyyy_MM_dd)$(Rev:r) which would produce a directory with the following name:

<my product name>_1.2.3.4_201203214