kayobe/doc/source/development/releases.rst

Releases

The project creator's guide provides information on release management. As Kayobe is not an official project, it cannot use the official release tooling in the openstack/releases repository.

There are various useful files in the openstack-infra/project-config repository. In particular, see the release.sh and make_branch.sh scripts.

Preparing for a release

Synchronise kayobe-config

Ensure that configuration defaults in kayobe-config are in sync with those under etc/kayobe in kayobe. This can be done via:

cp -aR kayobe/etc/kayobe/* kayobe-config/etc/kayobe

Commit the changes and submit for review.

Synchronise kayobe-config-dev

Ensure that configuration defaults in kayobe-config-dev are in sync with those in kayobe-config. This requires a little more care, since some configuration options have been changed from the defaults. Choose a method to suit you and be careful not to lose any configuration.

Commit the changes and submit for review.

Add a prelude to release notes

It's possible to add a prelude to the release notes for a particular release using a prelude section in a reno note.

Creating a release candidate

Prior to cutting a stable branch, the master branch should be tagged as a release candidate. This allows the reno tool to determine where to stop searching for release notes for the next release. The tag should take the following form: <release tag>.0rc$n, where $n is the release candidate number.

The tools/release.sh script in the kayobe repository can be used to tag a release and push it to Gerrit. For example, to tag and release the kayobe deliverable release candidate 4.0.0.0rc1 in the Queens series from the base of the stable/queens branch:

ref=$(git merge-base origin/stable/queens origin/master)
./tools/release.sh kayobe 4.0.0.0rc1 $ref queens

Creating a stable branch

Stable branches should be cut for each Kayobe deliverable (kayobe, kayobe-config, kayobe-config-dev).

To create a branch <new branch> at commit <ref>:

cd /path/to/repo
git checkout -b <new branch> <ref>
git review -s
git push gerrit <new branch>

After creating the branch, on the new branch:

• update the .gitreview file on the new branch, for example: https://review.openstack.org/609735
• update the references to upper-constraints to use the stable branch, For example https://review.openstack.org/#/c/568804.

For the kayobe repo only, on the master branch:

• update the release notes for the new release series: https://review.openstack.org/609742

Creating a release

Prerequisites

Creating a signed tagged release requires a GPG key to be used. There are various resources for how to set this up, including https://help.ubuntu.com/community/GnuPrivacyGuardHowto. Your default Gerrit email should be added to the key, and the key should be trusted ultimately, see https://wiki.openstack.org/wiki/Oslo/ReleaseProcess#Setting_Up_GPG for information.

Tagging a release

Tags should be created for each deliverable (kayobe, kayobe-config, kayobe-config-dev). Currently the same version is used for each.

The tools/release.sh script in the kayobe repository can be used to tag a release and push it to Gerrit. For example, to tag and release the kayobe deliverable version 4.0.0 in the Queens series from the tip of the stable/queens branch:

./tools/release.sh kayobe 4.0.0 origin/stable/queens queens

Post-release activites

An email will be sent to the release-announce mailing list about the new release.

The release notes and documentation are built automatically via a webhook.