• Support
• Documentation
• BuildMaster
• Core Concepts
• Releases

Releases

A Release represents a planned set of changes to an application. The release could be planned far in advance and require tens of thousands of developer hours to implement, or it could be a single line change rushed to production in an emergency.

Regardless of size or scope, releases are accomplished in a similar manner:

1. The required changes to the application are decided and generally then documented, sometimes in an issue tracking system or through some other tool or manual process.
2. Code changes are made to implement the requirements.
3. The code is compiled, built or otherwise assembled into a "build" and then deployed into a non-production application environment.
4. The non-production instance is tested and verified by users.
5. The build is then moved through a succession of other non-production environments for further testing.
6. When a bug or issue is uncovered during testing, further code changes are made, then run through the aforementioned build, deploy, and test steps.
7. Once a build has been verified as ready, it is deployed to production.

Releases in BuildMaster

Release Lifecycle

When a release is created, it begins in an active status. This means that the release is in progress (ie being developed and that new builds for that release may be created. As soon as one of the builds in the release is deployed to production, the release's status changes to deployed, and no further builds may be created against that release. If there are critical bugs in that release after deployment, then a separate release would be created to address those as needed. Any active release may be canceled; releases are generally canceled when the planned changes are no longer required or will go with another release.

Multiple Active Releases

Many organizations focus on developing a single release at a time. When that release is deployed, a new release is created. As such, by default, there can only be a single active release at a time.

BuildMaster does, however, support multiple active releases by enabling the "allow multiple" setting in the application's properties. The same general rules apply when there are two active releases.

Common scenarios for multiple active releases include:

• Deploying a patch release (1.4A) while 1.5 is still in development.
• Developing a far-out version (3.0) while a more current (2.4) is in development.

However, to get any notable value from multiple active releases, the appropriate development processes are needed, such as: branching capabilities in source control, alternate workflows, etc.

Release Ordering

Releases, which represent a set of changes, are logically sequenced by their release number. For example, 4.9 comes after 3.2, 1.7 comes before 1.10, 6.2A is after 6.2, etc. Furthermore, a later release always supersedes an earlier release: 3.0 contains the changes in 2.7, 2.3, etc, and 3.1 contains all of the changes in 3.0. As such, it is not logically possible for an earlier release to be deployed after a newer release

BuildMaster uses the release number to determine this deployment sequence, and releases are sequenced on the components of the release number:

[Major-integer].[Minor-integer].[Minor-character].[Revision-integer]

In addition, the following rules are enforced by BuildMaster:

• A release that's older than the latest deployed release cannot be created or un-canceled; e.g. 3.2 cannot be created when 3.7 is already in production.
• When a release is deployed, all older active releases are canceled; e.g. if both 1.2 and 2.0 are active, when 2.0 is deployed, 1.2 will be canceled.

Release Number

One of the key attributes of a release is the Release Number. It serves two important functions:

1. It uniquely identifies one particular release of an application distinctly from another release.
2. It determines the sequence of releases in an application relative to other releases.

Release numbers can be formatted in a number of different ways (eg 874, 8.74, 8.7.4, etc), and each of these formatting schemes are appropriate for different scenarios. BuildMaster supports three of the most common release numbering schemes.

Note that the release numbering scheme may only be selected when the application is first created.

Release Number Schemes

Major.Minor

This is the most popular scheme and consists of an integer-based "major" number and an integer+character-based "minor" number. While there are no formal rules that define how the major and minor numbers are to be used, many organizations use the following:

• Prior to a complete rollout of the application (such as a pilot type of implementation), the release number starts at 0.1.
• When the application is completely rolled-out, a major rewrite occurs, or a significant feature set is added, the major number is incremented and the minor number is reset to zero. 0.4 to 1.0, 1.7 to 2.0, etc.
• Non-major releases increment the minor number: 0.1 to 0.2, 1.9 to 1.10, 2.20 to 2.21, etc.
• Emergency and patch releases (ie releases in-between minor releases) add or increment a letter to the minor number. 0.1 to 0.1A, 1.10A to 1.10B, 2.2Z to 2.2ZA, etc.

Major.Minor.Revision

This scheme works almost exactly like major-minor, with the addition of an integer-based revision number. Also like major-minor, there are no formal rules for what constitutes a major, minor, or revision release, but many organizations use the following:

• Prior to a complete rollout of the application (such as a pilot type of implementation), the release number starts at 0.1.0.
• When the application is completely rolled-out, a major rewrite occurs, or a significant feature set is added, the major number is incremented and the minor number and revision number is reset to zero. 0.4.0 to 1.0.0, 1.7.9 to 2.0.0, etc.
• Non-major releases increment the minor number and reset the revision number to zero: 0.1.0 to 0.2.0, 1.9.4 to 1.10.0, 2.20.0 to 2.21.0, etc.
• Emergency and patch releases (ie releases in between minor releases) increment the revision number. 0.1.0 to 0.1.1, 2.6.9 to 2.6.10.

Minor numbers may be suffixed with a character, but that is generally not recommended as the revision number serves a similar purpose.

Note that the .NET framework and platform uses major-minor-revision+build numbers for assemblies, which make it convenient to automatically version assemblies based on the release number in BuildMaster.

Free Form

This approach uses an alpha-numeric release number and an optional integer-based revision number in a free form arrangement of characters and digits that may or may not have any specific meaning or connotation. The release number may take any format, though sequential and date-based are the most common. Many organizations use free form in one of two ways:

• Date Based – a number-based on the target date. For applications with a weekly schedule, this could be 20090108, 20090706, etc. Monthly releases could use the year and month: 200901, 200907, and quarterly could use the year-quarter: 20091, 200902.
• Sequential - the number is simply incremented with every new release.

Generally, the revision number is used for patches of in-between releases. Eg. 2009Q2 to 2009Q2.1 to 2009Q2.2, etc.

We recommend major-minor for most applications, as the majority of end users and testers are already familiar with the concept and will almost immediately understand a major-minor number to represent a certain release. This will help users identify bugs more easily and provides a common identifier for development and end-users.