SvnRevisionLabeller makes its v2 release

Recently Thoughtworks started to make available release candidates for version 1.4.4 of CruiseControl.NET. Tucked away inside there though are some changes to some of the core components, that break compatibility with SvnRevisionLabeller.

This gave me the proper motivation to find some time to finish off the packaging of a fairly major change to the way the labeller constructs build labels. The real work was actually done by another developer, fezguy - I just had to integrate his patch, tweak it to the way I like things (hey, it is my project after all!), and finally start work on some automated tests. I like automated tests.

Since the two changes combined do break backwards compatibility, it's good to take a step back and see where we are now.

Before, SvnRevisionLabeller was quite opinionated about how it thought build labels should be structured. With version 1.1, it was {major}.{minor}.{svnRevision}.{build} - {build} would start at 0, then if you forced another build without another commit having taken place, it would be incremented by one. A commit would then reset {build} back to 0, so you had a good idea how often the build was being forced. I later added the ability to specify prefix and suffix text for the label.

Version 1.3 saw me rethink things a bit, with the label now defaulting to {major}.{minor}.{build}.{svnRevision}; now, successive forced builds made no difference to the label. What it did give me was that when I deployed a hotfix to production (usually designated by the incremented {build} number), I could tell immediately which Subversion revision it was built with.

So it obviously works the way I wanted it to - but what about other people? Version 2.0 makes the label scheme very flexible - some tokens are defined, and you just position the tokens wherever you want them in a string pattern. So for instance, if I set my configuration thusly:

<labeller type="svnRevisionLabeller">
<major>1</major>
<minor>4</minor>
<build>2</build>
<pattern>Release v{major}.{minor}.{build} from {revision}</pattern>
</labeller>

then when revision 42 is committed, the build label will become Release v1.4.2 from 42. At work, I use the {build} number to represent the sprint number since we began working on the {minor} release.

Finally, I noticed that my project was not the only one to be caught out by CC.NET's upgrade - Codeplex's CC.NET Community Plugins are also broken by the change; unfortunately, they have a little more work to do, as it's not just a question of updating their external libraries and recompiling. I'm rather underwhelmed by the amount of activity on the site: I raised an issue earlier this month, and then submitted a patch to fix the issue, and it still hasn't been acknowledged yet, let alone added to the repository. For the time being, I won't be upgrading to v1.4.4 at work, since we need that library for our deployments.