How do you know what version number to use?

Question

Here\'s one I have always wondered about...

Please excuse my naivety, but - How do you decide what version number to name your software?

I assume, when someb

Answer 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.