Release and Version Numbering
AardRock standards for numbering releases, versions and builds of projects, products, or services.
The versioning scheme described in this document must be used in all artifacts throughout the product, including, but not limited to:
- about boxes
- splash screens
- build process
- documents
- source files
- manuals
- marketing collateral
The goal is for everyone to use the same scheme, everywhere.
Definitions
- QFE: Quick Fix Engineering, a.k.a. as HotFix or Bug Patch.
- RTM: Ready To Market—product function and quality are ready for the market at large.
Goals
- To provide a single consistent version numbering schema for all features and modules that comprise a project, product or service.
- To provide a schema that supports service pack releases.
- To provide a schema that supports a dot build release and have service packs and QFEs on the dot build release.
- To provide a schema that supports a multi-year project.
- To provide a schema that supports the ability for a developer to describe through the version number a developer built version.
- To provide a version numbering schema that supports installer, patching and upgrade technologies.
- To provide a version numbering schema that is consumable through programmatic interfaces, user interfaces and bug tracking databases.
- To provide a schema that supports release side-by-side installs. Note that there will be cases in which there will be a binary update vs. side by side install.
- To provide a release rhythm that feels natural and comfortable.
- To provide a release rhythm that accomodates the needs of (co-)developers and early adopters—happy with daily, weekly and monthly releases—and users requiring a more stable environment—happy with quarterly, semi-annual, or annual releases.
Seasonal Releases
The One Week Heart Beat or sprint—almost like a system clock—allows teams to adopt Three Or Four Week Iterations, creating a comfortable rhythm, not only for the entire organization, but also for the market.
These iterations naturally synchronize every quarter (12 + 1 weeks), leaving a full week for reflection and learning. This quarterly rhythm nicely facilitates Seasonal Releases (Spring, Summer, Fall, Winter) for eXtra Large releases or changes. They also often comfortably coincide with financial and business planning. Smoother synchronization can be achieved by adopting either a three week or four week across the board. Do whatever feels more natural, and try to avoid unnatural tension by adopting the right rhythm.
Larger intervals—a quarter or more—can be divided into Development Episodes or Phases.
The fully qualified Seasonal Releases versioning scheme is:
- company product season yyyy release.version.revision.build
For example:
- AardRock Cheetah Summer 2006 (2006.2.3.287)
Where:
| company | Company name. AardRock in our case. |
| product | The offical fully qualified name of the product, e.g. Cheetah. |
| season | The name of the season when this version of the product is released. This means that engineering is always working "ahead" of time. E.g. in the spring time, the engineering team is working on the summer release. |
| yyyy | Fully qualified year of release. E.g. 2006. Note that '06 or just 6 are incorrect. |
| release | Major version number. Equals the fully qualified year number, e.g. 2006. |
| version | Minor version number. The minor version number is synchronized with the season number, where Spring is season 1. |
| revision | Revision number. Revision numbers start at 0 and increment by by each time a HotFix or Service Pack is published. Revision numbers reset to zero when higher level numbers change. |
| build | Build number. The build number increments each time a new build is created. The build number is reset to 1 when higher level numbers change. |
Examples
TO BE SPECIFIED
File properties
The version information is to be written to the version properties of all binaries. The string “File version” reflects the release.version.revision.build version.
Service Packs
When deploying a service pack the version number of the actual product is not changed. Only the revision number gets incremented So the product looks like 2006.2.0.287 until we release SP1, then we’ll change the product version to 2006.2.1.45 to reflect the SP. This version number must be branded into all the files that comprise the product.