Sunday, March 9, 2014

One small step up




Versioning is always a difficult task. Usually it has some product meaning (Windows 8) and other time it expresses a marketing twist (jellybean).  As programmers, we usually don’t care about corporeal requirements.

.NET give us a basic and simple way to version our assemblies:
[assembly: AssemblyVersion("1.0.0.0")]

Like most of Microsoft infrastructure, we are only given tools that we can utilize and abuse in any way we’d like. Everyone has a different way of versioning components. I'm not going to discuss the theory of versioning, but I recommend reading this excellent article by the Github site founder at http://semver.org/.

So, I am going to talk about how I like to version my files.
I like to increase the build element of the version number whenever an assembly has changed between releases.



Simple rule. Hard to follow?


When there are only two projects in your solution, this rule is easy to follow because it can be manually managed. However, like one of my colleagues always says, “it doesn't scale”. Meaning, I have to manage a hundred projects, there is no way of tracking the changes between releases without a heavy dose of painkillers.

 
Finding excuses why not to do this, is exceptionally easy:
·        It’s easier to increase all the assemblies, like many build servers provide out of the box.
·        It’s also easier to match the executable version to the build counter.
·        Some might even go overboard and use the automatic build version "1.0.*".

 
All of these methods fail to follow the first and only rule – increase your version number whenever an assembly has changed between releases.

In order to follow this rule and avoid excuses, I’ve created a simple utility http://github.com/ronenbarak/Barak.VersionPatcher

This is a simple executable command line that can either be run manually or automatically by the build server. Its functionality is simple. It will search for changes in your source control, analyze your projects and generate the version number. Eventually it will check-in all the changes, all of this completely automatically.


Finally, I removed one more task off the release board (and actually did it right!).

This solution will probably not fit everyone, but if you want to version your files like I do, I’ve already done the heavy lifting for you. Just download the release published on github. If you don't like the way your files are versioned now and you don’t like the way I handled it, feel free to fork my implementation and customize your own.


Happy versioning!
 

No comments:

Post a Comment