How do you know what version number to use? - version

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 somebody creates a "final" version of an application/program it is version 1.0? - Then, what happens when you update it, how do you decide to call it 1.1 or 1.03 etc etc.
Is this mostly for the developer?

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.

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

Answer 3

We assign each build of any application unique four part version number defined as Major.Minor.Maintenance.Build.
Major -
The Major number is associated with significant changes to the application. This number also determines compatibility with other applications in the same "suite". This number is incremented when new releases are made. This usually means major architectural changes have taken place.
Minor - The Minor number is associated with new functionality and breaking bug fixes. Any time new functionality is introduced or when a breaking bug fix is applied, this number will be advanced and the Maintenance number will be set to zero.
Maintenance - The Maintenance number is associated with non-breaking bug fixes. This number will be advanced whenever a release is made that contains only non-break bug fixes.
Build - The Build number is associated with the subversion changeset (revision number) from which the application was compiled. This will provide an easy way of matching the version number to a precise set of code in subversion.
The only number the developers are really interested in this scheme is the Build. number. By tying the Build number to the subversion revision number we can guarantee what code was used to create the released application.

Answer 4

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 5

Whatever numbering scheme you pick, it is critical to make clear to your users when a new version is compatible with old client code versus when a new version requires changes to existing clients. Most projects I know bump the very first number when client code has to change.
Beyond compatibility, I too think there's a lot to be said for using dates. Although it gets embarrassing if, like me, your release schedule is once every two years (but that's for a tool first released in 1989).

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.

Answer 7

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 8

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 9

To add to all the explanation above, I will suggest use a versioning scheme which, will be easy for your customers to remember and easy for you to baseline and manage your software versions. Also, if you are supporting different framework such as .Net 1.0, .Net1.1 etc, then make sure your versioning scheme takes care of that also.

Answer 10

some good info here as well..
When to Change File/Assembly Versions
When to Change File/Assembly Versions
First of all, file versions and assembly versions need not coincide with each other. I recommend that file versions change with each build. But, don’t change assembly versions with each build just so that you can tell the difference between two versions of the same file; use the file version for that. Deciding when to change assembly versions takes some discussion of the types of builds to consider: shipping and non-shipping.
Non-Shipping Builds
In general, I recommend keeping non-shipping assembly versions the same between shipping builds. This avoids strongly-named assembly loading problems due to version mismatches. Some people prefer using publisher policy to redirect new assembly versions for each build. I recommend against that for non-shipping builds, however: it doesn’t avoid all of the loading problems. For example, if a partner x-copies your app, they may not know to install publisher policy. Then, your app will be broken for them, even though it works just fine on your machine.
But, if there are cases where different applications on the same machine need to bind to different versions of your assembly, I recommend giving those builds different assembly versions so that the correct one for each app can be used without having to use LoadFrom/etc.
Shipping Builds
As for whether it’s a good idea to change that version for shipping builds, it depends on how you want the binding to work for end-users. Do you want these builds to be side-by-side or in-place? Are there many changes between the two builds? Are they going to break some customers? Do you care that it breaks them (or do you want to force users to use your important updates)? If yes, you should consider incrementing the assembly version. But, then again, consider that doing that too many times can litter the user’s disk with outdated assemblies.
When You Change Your Assembly Versions
To change hardcoded versions to the new one, I recommend setting a variable to the version in a header file and replacing the hardcoding in sources with the variable. Then, run a pre-processor during the build to put in the correct version. I recommend changing versions right after shipping, not right before, so that there's more time to catch bugs due to the change.

Answer 11

In the case of a library, the version number tells you about the level of compatibility between two releases, and thus how difficult an upgrade will be.
A bug fix release needs to preserve binary, source, and serialization compatibility.
Minor releases mean different things to different projects, but usually they don't need to preserve source compatibility.
Major version numbers can break all three forms.
I wrote more about the rationale here.

Answer 12

It depends on the project. below is haskell's package versioning policy.
-- The package version. See the Haskell package versioning policy (PVP)
-- for standards guiding when and how versions should be incremented.
-- http://www.haskell.org/haskellwiki/Package_versioning_policy
-- PVP summary: +-+------- breaking API changes
-- | | +----- non-breaking API additions
-- | | | +--- code changes with no API change
version: 0.1.0.0