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.
- The current development branch is: 6.x-2.x
- The current stable branch is: 6.x-1.x
- Other branches
- Debian packaging:
upstream, see the debian documentation
- 7.x porting branch:
- Debian packaging:
- Active feature branches
2. Branch naming conventions
All branches are either development branches, stable branches or feature branches. Development and stable branches have the same naming convention:
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.
2.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 has been created when the 1.0 release was published. It is 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).
The development is not stable and should not be used in production environments.
Note that we have dropped the master branch as it is not well supported on Drupal.org for releases.
2.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-rc1 at least, and then be followed directly by
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
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.
2.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
3. Tag naming convention
Every release is tagged with a
6.x-x.y tag (e.g.
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.
4. 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.