Release Naming Strategy

This is my preferred Release Naming Strategy. Not a big deal if you disagree, at least you have a template so you can document your strategy.

Externally:
<major>.<minor>.<patch>
ex. 1.03.8

Internally:
<major>.<minor>.<patch>-<hudson-build-number>
ex. 1.03.8-27

<major> - Introduces major new functionality and often involves marketing. Resets the minor number to 00 and patch number to 0.
ex. 2.00.0 (May be referred to as the “2.0” release.)

<minor> - Indicates an addition of some features. Always two digits with pre-fixing zero for numbers less than ten. Releases should sort numerically, not alphabetically. This allows for a buffer of incremental minor releases before incrementing the major number which has different perception to the end user. Resets the patch number to 0.
ex. 1.09.0, 1.10.0, 1.11.0 (May refer to 1.11.0 as the “1.11” release.)

<patch> - Indicate a fix (ie. fixing a bug, improving performance, or an internal change without impacting functionality such as logging). Goes up by one every time a patch is officially added to the version. Use a single digit here because you should not have as many as 10 unplanned patches prior to a minor release.
ex. 1.03.1, 1.03.2, 1.03.3 and so on

Release Notes Template with Example