Friday, July 15, 2011

How to not suck at version numbers


Ever wonder what the right way to do versions numbers is? Well the truth is, there isn't one. But I think we can sure get closer than versions like: v0.124.120.12-M57-dev-beta-prerelease.




First of all. Let's discuss the concept of "beta" software. This is by far one of my least favorite things to see labeled on any software. You can thank Google for popularizing this phrase that has come to mean: Software we're too lazy to send through a proper FQA check. If you see this on a program, It could mean just about anything though. It's become more of a trend, and the word seems to get bigger and bigger on each product Google releases. Please, don't tag your version number with "beta".

There is, however, still a need for a pre-release state of software. Mainly on the first version. Since with open source projects becoming more popular, we can't expect the software to appear out of nowhere in a fully working state. This brings us to the concept of different release types.

A standard version number can be broken up into three types of releases: Major, minor, and bugfixes.

A Major release is the full release of your product. You idealistically expect everything in this release to be functional. It's new and it's a strong development in your product. Major releases would traditionally start with version one being the first available release to customers. This leaves room for a version zero: a version that is in a broken pre-release point. Version zero can never have any expectations, and should never be deployed on a production system out to customers. Once version zero is complete to your expectations, it is released as version one to customers.

A Minor release is catch-up work for a version of the software. It includes features that should have been implemented in the major release, but were left out for some reason. Any new features in development may be pushed to a minor release as well. Updates between minor releases should go 100% smoothly for the customer. There should be little or no trouble or manual data labor involved. This is the key difference between a major and a minor release. Major releases will involve data migration, whereas minor releases should be nothing more than adding a few needed features.

A bugfix release is fairly self explanatory. It indicates a critical release. Something you messed up and broke. Because these releases should be released to customers as soon as possible, they should not include more than one or two fixes per release. This makes it quicker to get through your QA system.



And that's it! Three numbers, all with distinct meanings. None of this "alpha release" crap. This means something. This is important.



Happy Coding!

No comments:

Post a Comment