Release process

Events happening in the community are now at Drupal community events on www.drupal.org.
You are viewing a wiki page. You are welcome to join the group and then edit it. Be bold!

This page aims to document our release process so that we never forget any parts of it.

In general, each major Hostmaster release comprises of a simultaneous release of all the modules part of the project. We generally go through a few releases before doing the first release. First an alpha is released to test new functionalities. When we feel we're getting close to a production-ready release, we bump that to a beta. Then we go into feature freeze and release a first release candidate (RC). If no critical bug is 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.

Every one of those releases should follow this process:

  • change versions in documentation and scripts (install.sh.txt, INSTALL.txt and UPGRADE.txt need to be modified manually, see this commit for an example, although that example lacks a modification to the AEGIR_VERSION in UPGRADE.txt)
  • tag the release in git. This means, for each module:
    git pull
    git push
    git tag hostmaster-0.4-alpha8
    git push --tags

    In the above case, we're tagging the 0.4-alpha8 release, the tag will vary according to branch and release state. Right now this means:
    • provision: provision-0.4-alpha8 (on master)
    • hostmaster: hostmaster-0.4-alpha8 (on master)
  • make a release announcement on the Group
  • revert the version changes done in the first step (see this sample commit for an example, although that one is still incomplete)

Tarballs are automatically created on http://files.aegirproject.org/ with associated md5sums once the tag is pushed.

Aegir hosting system

Group organizers

Group categories

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: