Aegir development makes a heavy use of branches to keep development stable. We use feature branches to do large development work and have release branches to keep stable releases maintained while development happen on the development branches.

1. The release cycle

In general, each major Aegir release comprises a simultaneous release of all the modules that are part of the project. We generally go through several testing releases (alphas, betas & RCs) before doing the first stable release on a branch.

• First an alpha is released to test new functionalities and to proceed accomplishing the goals decided in the Project Roadmap for that major version. Example: 0.4-alpha1, 0.4-alpha15
• When we have covered most of the functionalities outlined in the roadmap, we bump that to a beta. We push out beta releases until no more critical issues show up. Example: 0.4-beta1
• Then we go into feature freeze and release a first release candidate (RC). Then a stable release branch is created, we enter a feature freeze on that branch and master is kept opened for development for the next stable release. Example: 0.4-rc1, freeze announcement
• If no critical bugs are found, a complete release is done. Otherwise critical bugs are fixed and a new RC is done. That cycle repeats until no critical bugs are found, and a stable release is officially published.
• Once a stable release is out, hotfixes are committed to the stable branch, and a stable release is published (without alpha/beta/RC) directly on the stable branch.

2. Branch naming conventions

All branches are either development branches, stable branches or feature branches. Development and stable branches have the same naming convention: 6.x-1.x or 7.x-2.x. The only different between the two is that a stable branch is the branch where stable releases are published from.

Note: since the great git.drupal.org migration, we are back on Drupal.org and have been forced to change some of our naming convention, especially to include the core release number in the tag (so 6.x-1.x), which is a source of confusion for our provision module which supports any Drupal core version. See this issue on drupal.org for followup.

1.1. Main development branch

The main development branch is created after a fully stable release is published. For example, the 7.x-2.x branch will be created once the 1.0 release is published. It will be a development branch until it is considered feature-complete and goes through the alpha/beta/rc release cycle, at which point it will be declared a stable branch and a new development branch will be created (probably 8.x-3.x at that point).

Note that we have dropped the master branch as it is not well supported on Drupal.org for releases.

1.2. Stable release branches

Stable releases are performed from stable release branches. A branch is declared stable only after it went through the complete alpha/beta/rc release cycle, as detailed above..

Once the branch is declared stable, new releases are quickly done as "hotfixes", without intervening alpha/beta/rc releases. So for example, 6.x-1.0 will come after 6.x-1.0-alpha1, 6.x-1.0-beta1, 6.x-1.0-rc1 at least, and then be followed directly by 6.x-1.1.

Releases on the same stable branch are API-compatible with each other (so 1.1 is compatible with 1.0). The upgrade path is supported between major stable releases (so you can upgrade from 1.0 to 1.1 or 2.0).

Special case: during the 0.x release cycle, releases were not API-compatible with each other, ie. 0.4 was not compatible with 0.3, and you could barely upgrade from 0.3 to 0.4.

Only one stable branch is maintained at a time.

1.3. Feature branches

More complex development goes into development or "feature" branches, to avoid making master too unstable. Feature branches must be prefixed with "dev-" and use the issue number (if available or relevant) and a short name. So for example, there could be work on a dev-12345-mybug branch or dev-dns branch for a larger feature (DNS, in that case) which doesn't fit in a single issue.

Feature branches should be based of a known stable baseline as much as possible. For example, you should branch off the last alpha release if you want to make merging with other dev branches and master easier. See this article for a thorough discussion on this practice

2. Tag naming convention

Every release is tagged with a 6.x-x.y tag (e.g. 6.x-0.4, 6.x-0.4-alpha15 or 6.x-1.0). Those tags are usually laid on the stable branches, except for alpha/beta/rc releases which are laid on the development branch.

3. CVS and git history

The CVS tags and branches are still accessible in git and will be kept there for posterity. They respect the traditional Drupal.org naming convention.

They have also been converted to the new git.drupal.org conventions during the great git.drupal.org migration.

Since that migration (february 2011), history has been rewritten to clean up the authors in the history.