Daemonite: The science of version numbering Archive

Daemonite: The science of version numbering Archive

Tuesday, September 14, 2004
The science of version numbering

Version numbering seems more like art than science! Between the magic of marketing the reality of software programming there must be some method to the madness. Here are some thoughts on how Daemonites use the concept of version numbers.

First off we use CVS for just about everything code wise. Even the smallest one man coded operations we whack into version control. CVS has its own concept of revision numbers. If you use CVS at all its worth reading up on exactly how CVS determines its internal revision and version numbers

Basically CVS gives every separate file its own set of revision numbers. If you branch your code things get worse... more numbers. So these are really not any use for labelling your entire code base as a specific version. You have to come up with some other sort of system for that. Fortunately CVS has the ability to TAG your entire code base with a specific label that you can use in the future to revert or review the old snapshot of the code base. We use this TAGGING feature all the time to keep track of things.

CVS History Graph

This is a quick history graph of a file from Tortoise CVS. Note the revision numbers and the separate tags or labels.

We tag for a variety of reasons. Typically its a significant build of the code base. This can occur for any number of events, for example:

  • we believe the code base is stable and we are releasing it to QA for testing
  • we are burning the code base to CDROM to archive or distribute to a client
  • we are deploying the code base to a remote server

All of these events correspond to the development team losing control of the code base to a third-party.

We don't want to stop development to wait for their feedback. And especially with regard to distributing the code to clients we want to be sure that we can rebuild our workstations with exactly the code base that was distributed so we can track down any specific issue. If in doubt tag the code -- just be sure to give it the right name (more on this another day).

But tagging is not what we use to give the code base a "version number", like FarCry 2.2 -- we reserve that for specific milestone events. So how do we go about determining what number or tag that code base should have?

This rant from 2000 is still as relevant today as it was back then: Version numbering madness It talks about the perception people have about a software package based on the version number you have given it. For mainstream users, higher version numbers give the perception of stability, reliability and features. On the flipside of that, open source communities are less concerned about the version number itself except as a guide to the actual version you are running!

Look at the release cycle of ColdFusion. It went CF3, CF4, CF4.01, CF4.5, CF4.5sp1, CF4.5sp2, CF5, CFMX, CF6u1, CF6u2, CF6u3, CF6.1, CF6.1u1 and now we're talking CF7 (Blackstone). Despite the version number increase CF4.5 and CFMX for example were not paragons of reliability. What's with the change in number?? Why doesn't a service pack or updater correspond to a change in number??

I suspect that Macromedia's positioning in the market place has little if anything to do with the versioning practices of their development teams internally. Like other commercial software venders they need to focus buyers on specific major releases -- interim releases with minor functionality changes don't sell more software. This means simplistic version numbers.

Daemon is not involved in the production of licensed software. So we don't face the same issues. Our flagship product, FarCry CMS, is open source and so we can afford the luxury of incremental builds and releases without marketing and sales pressure. We need a version number that is relatively simple but tells people more about the actual state of the code base.

We pretty much follow the advice given in a rant about version numbers -- a good read and Zack's summary just makes sense to me.

For FarCry CMS we use a 3-digit version number (which gets abbreviated to two if the third digit is zero):

  1. The first is the major version. This number changes only when we make changes that break backward compatibility. So far we have only changed the major version if we have leveraged a feature in ColdFusion that relies on a newer version of CFMX. For example, FarCry 1 went to FarCry 2 when we started to leverage CFMX 6.1 specific code (CFC super() and so on). I suspect there will be a version change to FarCry 3 when Blackstone is finally released. Conceivably we could have a major version release if we overhauled an aspect of the code base that required significant change for existing sites or a loss of backward compatability in FarCry project code. Generally we try and avoid this at all cost.
  2. The second is the minor version. We increment this number after each significant development cycle, having made lots of improvements, probably introducing new bugs as well. For example, the release of FarCry 2.3 (due out shortly) will see the introduction of complete localisation of the admin interfaces and other great features. Significantly, these milestone releases in FarCry are the only builds that are commercially supported and that have a maintenance branch associated.
  3. The third is the patch level. We increment this number as the result of a bug-fixing cycle. A patch release should have strictly fewer bugs than the previous one, and no additional features. The current version of FarCry 2.2 has a maintenance branch on which we release new updates. So the latest 2.2 milestone is really 2.2.1

How do you treat version numbers?

Posted by modius at 03:28 PM | Permalink
Trackback: http://blog.daemon.com.au/cgi-bin/dmblog/mt-tb.cgi/246


At a previous employment, i implemented the versioning system that was basic in all sense, but also allowed us to keep track of multiple code bases.

The situation was, we had a number of products that were scheduled for release, the problem though was these products made use of 3 seperate CVS code librarys, each being their own seperate entity in development.

So when the product came to release, you had to not only tag each code base for release via CVS, but you also had to give the entire packaged code an umbrella release name..

So in order to this, we would go:

lib/x = 1.0.2
lib/y = 1.0.9
lib/m = 1.99.22
lib = 1.3.9b

We would append the letter "b" or "p", b=beta, p=production or in some special cases "d" (development release).

Once we tagged the entire package for release, we would continue on with the main trunk. However, if beta/production found a bug in the tagged release, we would fix it accordingly to that branch release code, while at the same time adding it to a known-bugs db for the continued (main trunk) development.

This way we could continue trunking along with the development, while part of the pre-beta QA was to double check bugs found (again) before we go to beta.

The other procedure was that once the product was past beta and into production, the b would then be replaced with p, and it would never revert back *unless a very good reason*.

Does that sound ok? I dunno, it seemed to work ok but whats your thoughts on it?

Posted by: Scott Barnes on September 14, 2004 05:07 PM