How do you know what version number to use?

Solution 1:

I've recently heard a pithier versioning strategy, that I first encountered at Eric Elliot's Medium account. It's more weighted towards library versioning that customer facing version numbers, but it has the advantage of simplicity. Use a three part version number, where each number means:

breaking.feature.fix

• breaking: Something has changed that means code/expectations must change
• feature: Something new is added, but old code/expectations will still work fine.
• fix: Nothing's new, but a bug has been fixed.

I leave my old answer below, as it's still relevant to customer facing versions.

I tend to weight the significant digits as follows....

w.x.y.z (or w.xyz)

• w - Major version, with many new features. A paid upgrade. The first public release of software is 1.X (pre-release versions are 0.X)
• x - Significant release, but without groundbreaking new features.
• y - Bugfix releases
• z - Patchlevel releases (fixing an emergency bug, perhaps just for one client).

If you choose to use the w.xyz format, you only get 9 digits before overflow. However, if you're releasing that often, you may have a bigger problem.

Let's illustrate with FooApp, my new product!

• 0.9 - The first public beta
• 0.91 - The second public beta
• 0.911 - The emergency beta release to fix a crash on the Motorola 68010
• 1.0 - The first public release
• 1.1 - Added new BlahBaz feature
• 1.11 - Bugfixes
• 2.0 - Totally redeveloped interface.

Solution 2:

Jeff Atwood has a blog post about this, where he advocates just using dates, and not to confuse the user with version numbers. However, he does discuss the approach Microsoft has taken: Using dates to determine version numbers. He goes into quite a bit of depth in his post, so I won't duplicate his work here. As for Versioning:

Versions (at least in .NET, go something like this):

1.2.3.4 where:

1 is the major release
2 is the minor release
3 is the build number
4 is the revision number

Major Release - Signifies a 'complete' system with whatever features that version was meant to have. Normally any subsequent 'major' versions are rewrites, or architecture changes, or (excuse the redundancy) major changes to the software.

Minor Release - Signifies a less significant release, with perhaps bug fixes, small features added, or any number of other 'minor' events. This could include interface changes and additions. Normally applications should be somewhat compatible in their 'major release' tree, so minor versions of the same major release should be architecturally the same.

Build Number - Generally signifies just bug fixes, small fixes, and are somewhat insignificant in their scope. It could be something as simple as changing the contrast between the foreground and background of the app. Generally, Builds are internal designations such as nightly builds, so you always have a place to revert back to that is stable.

Revision Number - signifies when bug fixes are released or VERY minor enhancements are made. These are generally reserved for just bug fixes -- don't include major feature enhancements as revisions.