These are the guidelines I follow in order to providing meaning to version numbers for any software. I found it simple to follow, hardly had to revise it and should be a matual guide to be shared with other developers.

Rule of thumb

• Versioning format is always: [major].[minor].[bulid].[revision]
• There’s no jump to version x.9 even if you are close to major release.
• Each number doesn’t have to be a single digit. You may have version 1.13.0 if minor release iterative continues.
• Hide revision number from non-developer release as the large trailing number tends to frown users. For example, release as 1.2.4 not 1.2.4.7658

Version Numbers

Version 0.1 – The public alpha

This is the very first version you annouce to general public. You should not yet push user to try out your software on this stage as the product is not complete: alpha serves as a concepture outlines of your software. It can sometime be used as a sample or teaser for marketing purpose.

Version 0.5 – The public beta

When you have captured and lockdown milestones for version 1.0 (and future roadmap), you should be ready for beta. This version contains all demostrable features set for version 1.0. There should still be many to-dos in your implementations such as validation, alternative scenario and exception. In beta, user should be able to have a go on all the features in version 1.0.

Version 0.9 – The release candidate (RC)

Upon completion of all implementations, give yourself sometime for perfomance tweak and bug fixes before jumping into version 1.0 as users will be expecting perfect working software. After release candidate, you should be focusing on stabilisation, performance and documentation. You may start encourage user to try out your product on RC.

x.0 – Major releases

For version 1.0, 2.0, 3.0 so on… They are major releases and should be either for major code refactor, introducing new features or provide significant functional updates. Anything minor such as functional adjustment, bug fixes are not qualified as a major release.

x.1 (except 0.1) – The dot one fix

Major releases tend to introduce new scenarios that hasn’t been tested and therefore bugs are released before spotted by users. It become more common now that software release so call “dot one fix” 1 month later to close majority of bugs and errors.

x.5 (except 0.5) – Half way check point

This release should contain major achievements since its major release. It also acts as a maintanace fork while working on the next major release. For example you may have just release 2.5, have 80% of your time working on 3.0 milestones while spending other 20% fixing bugs and therefore fork out to 2.5.1, 2.6 so on.