Versioning

Introduction

There are various version schemata around the software world and for CM5 the simplest has been choose that can cover all our needs.

Schema

MAJOR.MINOR.REVISION

The schema is not time[1] and stage[2] self-declarative.

Version Increment

• MAJOR: Major must be incremented when you have backwards API breakage.
• MINOR: Minor must be incremented when a new feature was implemented, a behavior was changed, or API enhancements have been made (that do NOT brake compatibility).
• REVISION: Revision must be incremented when a security issue or a usage bug has been fixed. User documentation or inline-code documentation has been updated.

To decide which segment you must increment, dependent on your changes you start from the rightmost(REVISION) with left direction. The first segment that can cover all your changes is choosen.

When incrementing a segment the other segments on the right must be reseted to zero.

Examples

• 1.0.0 => 1.0.1 To publish a release with hotfixes.
• 1.0.5 => 1.1.0 To publish a release with new featured (that do not break API) and hotfixes
• 1.1.5 => 1.2.0 To publish a release with only new featured (that do not break API)
• 1.1.2 => 1.1.3 To publish a release with updated documentation.
• 1.1.3 => 2.0.0 To publish a release with new API that breaks previous compatibility.

References

1. time-declarative: You can define the date of release by the version number (e.g. Ubuntu 10.4 is year 2010 month 04 (April))
2. stage-declarative: You can define the release stage (alpha, beta, rc) by its version number. For example all odd major are development and even release versions.