Version Numbers

Identifying when, how and whom produced a product is important. It is important with physical goods, hence why we have barcodes, expiry dates, model and serial numbers. The same is also true for software. Embedding a version number in files that ship with a product allow support team members to determine what version of the source code went into produce that version of the product and therefore more easily debug its observed behaviour.

Later this week I was working with a fellow team member on automatically applying version numbers to our product each time that it built (continuously integrated). On the surface it is quite a simple task except when you start to consider the sheer number of places that version numbers should be applied within a relatively complex build process. Here are some common examples:

  • .NET assemblies
  • NuGet packages
  • WiX installers
  • Documentation files

Each one of these target locations requires a different approach for finding and updating version numbers and it end up getting pretty complicated. But before you start you might want to give some consideration to what your version number actually looks like, and what it means.

I take a lot of inspiration from SemVer.org but it doesn’t really work for all technologies. For example, strongly named assemblies in .NET have four elements (major.minor.build.revision) whereas SemVer defines three elements (major.minor.patch). SemVer also defines trailing elements followed by a dash (for example 1.0.9-rc1) which won’t work for the strong name in a .NET assembly. Of course we can use other informational versioning techniques to pass along SemVer like version information.

If we look at SemVer and apply the first part (major.minor.patch) to version numbers within the package then we could probably adopt a manual version increment technique and just take a centrally defined version number (say in version.xml in the root of the solution) and stamp it in various files during the build process.

Anyway – version numbers, they are important!

3 thoughts on “Version Numbers

  1. thomasswilliams

    G’day Mitch – I’ve got into the habit of displaying version numbers as YYYYMMDD. Underneath they’re still the .NET versions, however for end-users I “translate” them. Works for me, and means I worry less about the difference between file version, .NET version, and installer version (which are all different).

    Helpfully, end-users have actually quoted the YYYYMMDD number to me, usually they stop after the 2nd or 3rd dot when reading out regular major.minor.build.release numbers.

    Thomas

  2. Mitch Denny Post author

    Hi Thomas,

    How do you go when you get more than one build happening a minute? For what it is worth, I do ultimately agree with you. I almost always figure out a way of stamping the actual build number somewhere into the files (just in case the versioning mechanism breaks for some reason). So if I was using TFS I might end up with something like Trunk_Product_20120901.13 (thirteenth build on the 1st of September).

  3. thomasswilliams

    Hmmm, more than one build even a day becomes problematic. In that case having end-users take notice of the version number sort of comes back to bite you!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s