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

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 2

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

With Agile software development practices and SaaS applications, the idea of a Major vs. a Minor release has gone away - releases come out extremely frequently on a regular basis - so a release numbering scheme that relies on this distinction is no longer useful to me.

My company uses a numbering scheme that takes the last 2 digits of the year the release started followed by the release number within that year.

So, the 4th release started in 2012 would be 12.4.

You can include a "bug fix" version number after that if necessary, but ideally you are releasing frequently enough that these are not often necessary - so "12.4.2".

This is a very simple scheme and has not given us any of the problems of other release numbering schemes that I have used before.

Answer 5

We prefer major.minor.milestone.revision-build scheme, where:

• major: Increments upon significant architectural changes or important advancements in capabilities.
• minor: Small changes and new features that does not require architectural changes.
• milestone: Indicates stability and maturity of the code:
  • 0 for development/pre-alpha
  • 1 for alpha
  • 2 for beta
  • 3 for release candidate (RC)
  • 4 for final/production release
• revision: Indicates release, patch or bugfix number.
• build: Unique references to specific builds, or versions, of an application. Build number is a sequential integer, typically incremented at each build.

Examples:

• 1.4.2.0-798: First beta release of version 1.4, created by build number 798.
• 1.8.3.4-970: 1.8-RC4, created by build number 970.
• 1.9.4.0-986: First production release of version 1.9, created by build number 986.
• 1.9.4.2-990: Second bugfix release of version 1.9, created by build number 990.

Since prodcution releases always have 4 in their 3rd digit of version string, the digit may be removed for production releases.

Answer 6

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