Develop Version Numbering for an Application

Question

Firstly, I think this forum is not appropriate for my question, so if it is in wrong place, kindly forgive and place wherever appropriate. I didn\'t find proper forum for my que

Answer 1

In BuildMaster, we consider the #.#.#.# release number format to represent:

[major version].[minor version].[maintenance version].[build number]

Since mostly I would be regurgitating information from our blog, I'll just give you a link to the article written by a colleague of mine: http://blog.inedo.com/2011/03/15/release-numbering-best-practices/

When it comes to updating your release numbers, I would just leave the local development version at 0.0.0.0 and let your automated build process worry about the numbering.

Answer 2

We use major.minor[.build[.revision]]. And we give the semantics of:

major = major version. (Kind of big changes, maybe even with UI refresh). minor = as medium set of changes. (maybe new internal processes or engines' refactoring).

As for build and revision:

0 - Means its alpha stage.
1 - Beta.
2 - Release candidate.
3 - Production.

So, if your app its on 3.2.1.0. You know you're at the alpha stage of the 3.2 version. And so on.

NOTE: Although it may seems kinda large to include the revision we found it to be a good practice because if we found some bug or unexpected behavior we just fix and increment revision and not build.

Answer 3

I think - and this comes from my experience, not just an idea - that you should use 4 part version numbering - very much along the lines of @Randolf. However I would make a different definition of the parts and the versioning.

major - this should be incremented when the version is a new build, is not compatible with previous versions without an upgrade process, or when the build/development platform changes ( so moving from .net 2.0 to .net 4.0 would count.

minor - this should be incremented when the data structures underlying your application change ( whether this is a db or not ). This means that a data build or update will be needed, which for clients indicates the level of work that may be needed for an upgrade.

build - this should always be incremented whenever a full production build is made, as a release candidate.

revision - this should be updated for every build, and used for bug fixes on a release candidate.

This means that you can identify with the version number exactly which changes and fixes are in that release, which is crucial for support.

Manual or automatic - this route would imply a manual update, and this is important to enable you to identify what a release contains.

Release and development version numbers should generally be the same, becasue the version number should only be incremented when a build for potential release is made. Having said that, you should also make sure that you can do development on any supported version, which may be lower than current development version, if a new release is in testing.

Answer 4

Frustratingly, .Net seems to consider build numbers the 'wrong' way round, according to many people. AssemblyInfo specifies build number as [Major][Minor][Build][Revision], which to me doesn't make any sense. Surely a nightly build happens more often than a revision of the spec, and is therefore the 'smallest' change? I'm not going to fight against the framework though, so I'm just going to have to tolerate it.

Maybe it's the same root cause as the phenomenon of Americans specifying dates in the wrong order. Again, common sense would dictate large->small consistently.

With regards to organising this conceptually, I would say that each part of a four-part build number should indicate the most recent change of the appropriate magnitude; i.e:

Major: A major upgrade of the application, which you expect users to pay for if it's a commercial project. Users should expect to face infrastructure concerns, such as service packs and new .Net versions;

Minor: A significant rollup of bug fixes and change requests that would fulfil the description of 'small feature'. Anything that should arguably have been in the program already can be rolled into a minor version;

Build: Personal choice, but for me this would be the unique build number. If you get your binaries from an integration server, this could run into the tens of thousands. Likely to be a nightly build, but could also be built on demand when the PM says 'go'. The build number should uniquely correspond to an event that kicked off a full production build on the integration server.

Revision: Should correspond to an amendment to the specification, at least conceptually. Would typically match an item in the changelog i.e. all incremental changes up to and including change request x.