Change Management: Project Release Numbering

In a previous post I said I'd post something about my numbering scheme for release candidates. If you recall from the previous post, a release candidate is the set of code that will be moved from development to a higher environment. They are complete enough that by packaging and releasing them we are saying 'this set of items can move into production'. This is the key to change management in these environments. If you are working in an Agile environment you may have a release every iteration, if not you may be releasing things more infrequently than that. This system is meant to be simple and fit with the change management process defined in the earlier post.

Any version numbering scheme should be developed to fit your change management process. An initial version of a project will be Version 1. Changes after that are tracked using our numbering system below. A change will increment either the major or minor revision number (very loosely and very purposefully defined as 'depending on the impact of that change') as follows;

• A Version Number is incremented when a project is wholly changed or rebuilt.
• A major change to a version will increment the Major Revision Number.
• A minor change to a version will increment the Minor Revision Number.
• A Patch can be applied if a change to an existing version is required (rather than a rebuild and increment). Additional patches increment the Patch Number.

Any specific release can be recreated by starting with that version's code sequentially applying all patches.

*Note, In my environment I don't need release things to users before they are production ready. If you you wish to denote that something being released to customers is in a pre-production state, I would call that a version 0, use the numbering scheme above for changes to that product and attach a greek alphabet prefix (Alpha, Beta, etc) to each release version in this pre production state.

See Also:

• Agile BI - Ralph Hughes