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

This is what I use for modules in embedded C projects:

1.00 - Initial release

1.01 - Minor revision
No interface changes to the module (i.e. header file didnt change). Anybody using my module can upgrade without having to be afraid of breaking code. I might have done some refactoring or code cleanup.

2.00 - Major revision
Module interface changed (i.e. functions added, removed or functionality of certain functions changed). An upgrade to this revision will most likely break existing code and will require refactoring of code using this module.

I should add that this refers to development stage, i.e. internal releases of modules into the project.

Answer 2

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.

Answer 3

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.

Answer 4

A.B.C.D

• A: 0 when beta, 1 when first release, larger then 1 on almost entire rewrite.
• B: New features added
• C: Bug fixes done
• The revision number of the version control repository

Answer 5

I think that the Linux kernel is a good reference for this:

The version number of the Linux kernel currently consists of four numbers, following a recent change in the long-standing policy of a three-number versioning scheme. For illustration, let it be assumed that the version number is composed thus: A.B.C[.D] (e.g. 2.2.1, 2.4.13 or 2.6.12.3).

* The A number denotes the kernel version. It is rarely changed, and

only when major changes in the code and the concept of the kernel occur. It has been changed twice in the history of the kernel: In 1994 (version 1.0) and in 1996 (version 2.0).

* The B number denotes the major revision of the kernel.
      o Prior to the Linux 2.6.x series, even numbers indicate a stable

release, i.e. one that is deemed fit for production use, such as 1.2, 2.4 or 2.6. Odd numbers have historically been development releases, such as 1.1 or 2.5. They were for testing new features and drivers until they became sufficiently stable to be included in a stable release. It was an even/odd version number scheme. o Starting with the Linux 2.6.x series, there is no significance to even or odd numbers, with new feature development going on in the same kernel series. Linus Torvalds has stated that this will be the model for the foreseeable future.

* The C number indicates the minor revision of the kernel. In the old

three-number versioning scheme, this was changed when security patches, bug fixes, new features or drivers were implemented in the kernel. With the new policy, however, it is only changed when new drivers or features are introduced; minor fixes are handled by the D number.

* A D number first occurred when a grave error, which required immediate

fixing, was encountered in 2.6.8's NFS code. However, there were not enough other changes to legitimize the release of a new minor revision (which would have been 2.6.9). So, 2.6.8.1 was released, with the only change being the fix of that error. With 2.6.11, this was adopted as the new official versioning policy. Bug-fixes and security patches are now managed by the fourth number, whereas bigger changes are only implemented in minor revision changes (the C number). The D number is also associated with the number of times that the compiler has built the kernel, and thus is called the "build number."

Also, sometimes after the version there will be some more letters such as 'rc1' or 'mm2'. The 'rc' refers to release candidate and indicates a non-official release. Other letters are usually (but not always) the initials of a person. This indicates a development branch of the kernel by that person. e.g. ck stands for Con Kolivas, ac stands for Alan Cox, whereas mm stood for Andrew Morton. Sometimes, the letters are related to the primary development area of the branch the kernel is built from, for example, wl indicates a wireless networking test build.

From http://en.wikipedia.org/wiki/Linux_kernel#Version_numbering

Answer 6

More than likely some one in sales or marketing will decide that they need some buzz. This will determine if the next release is 1.01 or 1.1 or 2.0. Kind of works the same in open source but it tends to tied to a fancy new feature that the team is proud of.