My Software Release Numbering System

I am about to release a new version of salt, and hopefully in the next week I will be releasing the first alpha of the butter cloud controller. As you may also be aware I have also released Varch, the virtual machine builder for Arch Linux.

So with this in mind, I thought it would be a good idea to explain my software numbering scheme. I adopted this method because I dislike the concept of software that is perpetually release 0.<something> and I like the idea of being somewhat “done”. This method is a good gauge for determining what the state of the software is, which in my mind is a good motto for numbering software. I think that with open source projects there is little need for the numbering system to be a marketing component, but it should be more than just incrementing an arbitrary number for package managers.

Early Development

When a project is in early development the numbering is between 0.0.0 and 0.4.0, these are rarely if ever released because they reflect development milestones for backend library work. Any numbering is strictly used in the scm repo and tarball releases are not produced.

Alpha Releases

0.5.0 and 0.6.0 reflect alpha software releases, 0.5.0 is used when the initial operation chain, from command line to core operation or the project daemon can start and has some functionality. 0.5 series releases are let loose in a KDE 4.0 kind of way, they are for “developers and technology preview” and not for general consumption.

0.6.0 is often the first public release, this reflects a usable product. But 0.6 series releases are often still unstable and missing features, they are functional and “core complete”.

Beta Series

0.7.0 and 0.8.0 series reflect beta series software. These releases are often production ready but can still be rough around the corners and missing some primary features. Some software, like Varch, may stay here for a very long time, because the software could be happily fulfilling my intention for having written it. If a peice of software stays at the 0.8 series for a while I may bump the version directly to stable.

Release Series

0.9.0 and to 1.0 mark the release series. Once software has hit 0.9 it should no longer have any serious defects and be over %90 feature complete. 0.9 releases should be production quality and is considered to be under testing for the 1.0 series.

Once the software has been thoroughly tested and proven in production it will be bumped to 1.0. Usually at this point the software has matured and many new ideas as to features become evident. Following 1.0, 1.1, 1.2 and up to 1.6 can be feature inclusions.

Moving to 2.0 would mean a feature freeze at a 1.x release and then starting at 1.7 and moving along the same lines toward a 2.0 release.


All in all I think it is pretty straightforward and hopefully this article helps reflect where I think my software is.


3 responses to this post.

  1. Posted by John Walker on April 16, 2011 at 1:27 pm

    I realize that I am critiquing a decision that is yours exclusively… 😉

    – so what happens when you are at x.6 and you have a new feature (minor) release? Does that force 2.0 or 1.9?
    – so x.6 is stable, but x.7 is a beta?
    – 0.6 is alpha, but (1+).6 is a stable release?
    – do you use major versions to mark (significant) backward compatibility or architecture changes? It seems like “no” from these examples…

    This may seem like nit-picking, but I have been at several jobs where we were into more than 5 or 6 (minor) releases of a product (typically internal tools and layers used for games and game engines).

    Maybe your programming fu (unlike mine) is strong enough to say that “I seldom need anything beyond a .2”

    (I also reject the notion that “two digit minor/micro/nano version numbers are wrong”, but that is my opinion.)


  2. I think that the main problem I have with this is moving towards 2.0.
    To be honest the problem has not really come up yet, and my system has only ever been used to approach 1.0.

    Unlike you John, my coding fu is still very weak, and I will probably be asking for your advice when I begin to approach 2.0 releases!


  3. Tom, you’re awesome, and your blog is now in my feed aggregator. With that said, here’s my 2 cents on software versioning:

    I generally prefer release dates to software version numbers, than anything else. The communicate to the person _when_ the release happened, as most don’t care about whether or not something is a “minor” or “major” release. Canonical got this right with Ubuntu, but unfortunately, the community hasn’t seemed to have clued in, and prefer to call Ubuntu by their lame release names instead (which give no indication on when the release took place).

    While “1.0.5” might communicate volumes of the “stability” and “features” of the software, most people don’t care about that. Only devs. However, “11.04” communicates when the release actually took place, and people can immediately identify if their software is out of date.


Leave a Reply

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

You are commenting using your 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

%d bloggers like this: