1

This is a complicated one, so I hope I explain it well enough.

Background

I'm in the process of automating a build process with CruiseControl.NET and NAnt. The biggest headache I'm encounting is version number format and CruiseControl.NET requiring the label from a labeller before running a build project.

Currently a developer runs Visual Studio 2008 to produce a Debug, Release and Custom build. Each of these configurations invoke BuildInc (a custom tool) that reads a file (version.ver) increments the read version number, generates an .rc2 file for the executable properties and writes a new version back to version.ver. Obviously version.ver and .rc2 change and need checking backing into source before the developer labels the release in source control. The label in source control is the version number i.e. 1.2.3.4 -> 1-2-3-4.

Currently the new automated build triggers a CruiseControl.NET project that invokes a NAnt script. The NAnt script runs Visual Studio and publishes the builds to a release directory. That works fine, the NAnt script is able to get the previous and new version number by reading version.ver. The problem is getting CruiseControl.NET to label the source and display the label on the dashboard. The new version number/label is generated during the build and which number to increment is held within the Visual Studio project in the pre-link tasks arguments.

Version numbers

Version numbers are in a unique format and are different between builds done on trunk and a development branches. Builds done on a branch are for enhancements that are merged back into trunk when completed.

Trunk

  • Format: [Major].[Merge].[Release].00 i.e. 42.01.02.00
  • Major: System number
  • Merge: Incremented if a branch is merged
  • Release: Incremented on bug fixes

Branch

  • Format [Major].00.[Stream].[Release] i.e. 42.00.01.01
  • Major: System number
  • Stream: Stream number, linking it to other components for the enhancement
  • Release: Incremented on bug fixes

Numbers are prefixed by zero i.e. 01, 02. This doesn't play well with any tools I'm encountered. (I'm hoping to change that)

Questions

After all that I hope you understand my problems.

  1. What general improvements could I make to the automated process?
  2. Do you think the version number should be known before the build is started?
  3. Should the automate build system auto increment the version number?
  4. Should I consider changing the version number format?
  5. Any other comments, I really need more opinions.

Let me know if more information is needed.

Notes

Language is C++, platform is Windows and source control is CVS.

  • Are you making separate projects in cruise control .net for branches and trunk? – Mahesh KP Jul 21 '11 at 11:32
  • Yes I am, the trunk project will continue ticking along, whereas branch projects will be added and removed as necessary. –  Jul 21 '11 at 14:05

1 Answers1

1

You can add a post build event to your project which will write the latest build number (in whatever format you want) to a text file, say label.txt, in your source folder.

Then add a fileLabeller type labeling to get the latest version number which will take the version number from label.txt.

<labeller type="fileLabeller">
   <labelFilePath>ProjectFolder\label.txt</labelFilePath>
   <allowDuplicateSubsequentLabels>true</allowDuplicateSubsequentLabels>
</labeller>
JV.
  • 3,193
  • 1
  • 20
  • 21
Mahesh KP
  • 6,248
  • 13
  • 50
  • 71
  • But the documentation says "The file is read just before the first pre-build task is executed.", so would this work? http://confluence.public.thoughtworks.org/display/CCNET/File+Labeller – JV. Jul 22 '11 at 08:41
  • i mean if you run the code from visual studio it will create the label in text file and commit this file along with source code. So in the next ci build it will show the label in the text file – Mahesh KP Jul 22 '11 at 09:20
  • Ah yes, I see. I was thinking more of my builds where the build number is not known until the build is underway (void's question 2). Thanks for the clarification. – JV. Jul 26 '11 at 14:16