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.