« Comment spam sucks. | Main | Ah, Technology. »

January 29, 2005

Better Build Numbers

Geek mode on!

In developing my junky little Mac application, I found myself wondering how best to manage software release numbers. Marketing numbers like 1.5 are all well and good, but how do I keep track of what version of the code a particular user has? And when I'm distributing betas (which I don't bother tagging in the code repository), how do I know which revision they came from? It makes all the difference in stomping bugs.

I briefly toyed with the software updating its own build number every time I compiled it, but that sucked. My testing is very much hands-on as opposed to reading through the code, for various reasons -- but mainly that Obj-C can be a little quirky at times, and that the code looks brilliant anyway after you've spend the last x time units writing it. When you test that way, build numbers increment disturbingly quickly.

Using Subversion for my SCM solution, the answer hit me like a load of bricks: use the repository's revision number as a unique identifier.

And so betas started going out that way for testing. I sent out beta 66 for testing, got reports back, made the necessary changes, and sent out 67. It made things damn easy. When users report a bug in a beta, I can very very easily pull exactly what they were using without polluting the repository with tags for beta releases. I don't have any wide-reaching beta program, so betas get sent out individually as bug reports come in -- I may have 2 or 3 different betas floating around at a given moment.

While it no longer increments its own numbers (though I'm sure I could write a script to make it do that if I was bothered enough), it takes me all of 10 seconds to edit the two files containing the build number. Simple enough.

On the topic of SCM: Perforce is crazy. I briefly toyed with it because I didn't want the hassle of compiling Subversion. The setup documentation for Perforce has a tendency to explain how to do something with Perforce-specific terms that aren't explained. While I may have been able to figure it out eventually, I didn't have the patience to play games (especially when I'm really unlikely to sink the $800 on it when Subversion performs just fine). Perforce may have some spiffy features, but I'm my IT department and my IT department decided to take a coffee break and get some real work done instead.

Posted by Colin at January 29, 2005 9:54 PM

Trackback Pings

TrackBack URL for this entry:


Post a comment

Remember Me?

(you may use HTML tags for style)