What version numbering scheme do you recommend?

Question

My question is, which version-naming scheme should be used for what type of project.

Very common is major.minor.fix, but even this can lead to 4 number (i.e. Firefox 2.0.0.16). Some have a model that odd numbers indicate developer-versions and even numbers stable releases. And all sorts of additions can enter the mix, like -dev3, -rc1, SP2 etc.

Exists reasons to prefer one scheme over another and should different type of projects (i.e. Open Source vs. Closed Source) have different version naming schemes?

Answer 1

This previous discussion may help.

Answer 2

I personally prefer MAJOR.MINOR.BUGFIX-SUFFIX where SUFFIX is dev for development versions (version control checkouts), rc1 / rc2 for release candidates and no suffix for release versions.

If you have suffixes for development checkouts, maybe even with the revision number, there is no need to make them even/odd to keep them apart.

Answer 3

The difference between a close and open-source version number policy can also come from a commercial aspect, when the major version can reflect the year of the release for instance.

Answer 4

This kind of question is more about religion war than objective aspects. There is always tons of pros and cons against a numbering scheme or another. All what people could (or should) give you is the scheme they used and why they choose it.

On my side, I use a X.Y.Z scheme all are numbers where:

• X indicate a change in the public API that introduce backward incompatibility
• Y indicate an addition of some features
• Z indicate a fix (either fixing a bug, either changing internal structure without impacting functionnality)

Eventually, I use "Beta N" suffix if I want some feedback from the users before an official release is done. No "RC" suffix as nobody is perfect and there will always be bugs ;-)

Answer 5

Here's what we use in our company: Major.Minor.Patch version.Build Number .

The Major change involves a full release cycle, including marketing involvement etc. This number is controled by forces outside of R&D (for example, in one of the places I worked, Marketing decided that our next version would be '11' - to match a competitor. We were at version 2 at the time :)).

Minor is changed when a new feature or a major behavior change is added to the product.

Patch version goes up by one every time a patch is officially added to the version, usually including bug fixes only.

Build Version is used when a special version is released for a customer, usually with a bug fix specific to him. Usually that fix will be rolled up for the next patch or minor version (and Product Management usually marks the bug as "will be released for patch 3" in our tracking system).

Answer 6

Our R&D department uses 1.0.0.0.0.000: MAJOR.minor.patch.audience.critical_situation.build

Please, please, don't do that.

Answer 7

What we used to do here is major.minor.platform.fix.

major: We increase this number when saved file from this build are no longer compatible with previous build.
Exemple: Files saved in version 3.0.0.0 won't be compatible with version 2.5.0.0.

minor: We increase this number when a new feature has been added. This feature should be seen by the user. Not a hidden feature for developper. This number is reset to 0 when major is incremented.

platform: This is the platform we use for developpement.
Exemple: 1 stands for .net framework version 3.5.

fix : We increase this number when only bug fixes are included with this new version. This number is reset to 0 when major or minor is incremented.

Answer 8

Simply

Major.Minor.Revision.Build

Answer 9

There are two good answers for this (plus a lot of personal preferences, see gizmo's comment on religious wars)

For public applications, the standard Major.Minor.Revision.Build works best IMO - public users can easily tell what version of the program they have, and to some degree, how far out of date their version is.

For in house applications, where the users never asked for the application, the deployment is handled by IT, and users will be calling the help desk, I found the Year.Month.Day.Build to work better in a lot of situations. This version number can thus be decoded to provide more useful information to the help desk then the public versioning number scheme.

However at the end of the day I would make one recomendation above all else - use a system you can keep consistent. If there is a system that you can setup/script your compiler to automatically use everytime, use that.

The worst thing that can happen is you releasing binaries with the same version number as the previous ones - I've recently been dealing with automated network error reports (someone elses application), and came to the conclusion that the Year.Month.Day.Build version numbers shown in the core dumps where not even remotely up to date with the application itself (the application itself used a splash screen with the real numbers - which of course where not drawn from the binary as one might assume). The result is I have no way of knowing if crash dumps are coming from a 2 year old binary (what the version number indicates) or a 2 month old binary, and thus no way of getting the right source code (no source control either!)