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.
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.
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.
It’s possible to add a prelude to the release notes for a particular release
using a prelude
section in a reno
note.
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
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:
.gitreview
file on the new branch, for example:
https://review.openstack.org/609735For the kayobe repo only, on the master branch:
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.
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
An email will be sent to the release-announce mailing list about the new release.
Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.