Releasing a new version of Quattor

Table of Contents

1. Introduction
2. Release branch
3. Tools
4. Testing the release
5. Uploading to the Git repositories

Introduction

As discussed in the 15th Quattor workshop, I detail here the tools and means for a Quattor release. This document should be kept up to date as the release procedure gets more automated.

We do one release approximately every two months. The "certification" process is partly automated, here is how it goes:

Release branch

A week before release date, the RM announces a merge freeze on all repositories, this means that no new features should be merged, only fixes for serious issues discovered in the current code-base.

The RM merges any pull-requests that need to be in the release.

If necessary, the release manager (RM) creates a new branch in the main GitHub repository, on each repository that will be released, however most repositories will be released from master.

The RM ensures that the builds in the ​Jenkins repository pass. If they don't, he iterates with the authors or reverts the commits that break the tests.

Tools

The ​release repository contains the releaser.sh script for performing releases, this is now the preferred method of performing a Quattor release. This builds packages, tags the GitHub repositories, collects and signs the RPMs and generates a signed YUM repository in a tar-ball.

At least one release candidate should be built before a final release, more often than not several will be required!

Release numbering is of the format YY.M.P where P is a point-release number, starting at 0. Point releases should only be necessary in exceptional circumstances. For example: a fix from a later release needs to be back-ported to an earlier one and for various reasons several sites are unable to update to the newer release (perhaps due to the bug!).

Release candidates are suffixed with -rcN where N is the RC number. For example:

• 14.5.0 (final)
• 14.6.0-rc1 (release candidate 1)

Testing the release

When all tests seem to pass, the RM uploads the repository tar-ball to the to yum.quattor.org and publishes it under /testing/.

The RM announces the availability of the RC and requests site testing.

NOTE: We don't have the manpower to produce test profiles for each component. Only the most important ones are being stressed ATM.

NOTE: We'd appreciate a number of virtual machines (or a test site in the cloud) to make even more thorough tests.

Uploading to the Git repositories

The ​release repository contains a POM file with all the artifacts that should be uploaded to the Yum repositories, with their releases. Just adjust it.