Mark Goddard 6e1def534c Update documentation for release tasks

Since Kayobe is now an official OpenStack deliverable, our releases
documentation page is now outdated. It needs to be updated to document
the process using official release tools.

This change makes the releases page more similar to the Kolla release
management page:
https://docs.openstack.org/kolla/latest/contributor/release-management.html.

Change-Id: Ic49a63d66dfdb8e4235a60c1f01ad70bef6bea43
Story: 2007079
Task: 37990

2020-04-02 16:23:43 +00:00

5.7 KiB

Raw Blame History

Releases

This guide is intended to complement the OpenStack releases site, and the project team guide's section on release management.

Team members make themselves familiar with the release schedule for the current release, for example https://releases.openstack.org/train/schedule.html.

Release Model

As a deployment project, Kayobe's release model differs from many other OpenStack projects. Kayobe follows the cycle-trailing release model, to allow time after the OpenStack coordinated release to wait for distribution packages and support new features. This gives us three months after the final release to prepare our final releases. Users are typically keen to try out the new release, so we should aim to release as early as possible while ensuring we have confidence in the release.

Release Schedule

While we don't wish to repeat the OpenStack release documentation, we will point out the high level schedule, and draw attention to areas where our process is different.

Milestones

At each of the various release milestones, pay attention to what other projects are doing.

Feature Freeze

As with projects following the common release model, Kayobe uses a feature freeze period to allow the code to stabilise prior to release. There is no official feature freeze date for the cycle-trailing model, but we typically freeze around three weeks after the common feature freeze. During this time, no features should be merged to the master branch.

Before RC1

Prior to creating a release candidate and stable branch, the following tasks should be performed.

Testing

Test the code and fix at a minimum all critical issues.

Update dependencies to upcoming release

Prior to the release, we update the dependencies and upper constraints on the master branch to use the upcoming release. This is now quite easy to do, following the introduction of the openstack_release variable. This is done prior to creating a release candidate. For example, see https://review.opendev.org/#/c/694616/.

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.

Prepare 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.

Ensure that release notes added during the release cycle are tidy and consistent. The following command is useful to list release notes added this cycle:

git diff --name-only origin/stable/<previous release> -- releasenotes/

RC1

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.

This should be done for each deliverable using the releases tooling. A release candidate and stable branch defintitions should be added for each Kayobe deliverable (kayobe, kayobe-config, kayobe-config-dev). These are defined in deliverables/<release name>/kayobe.yaml. Currently the same version is used for each deliverable.

The changes should be proposed to the releases repository. For example: https://review.opendev.org/#/c/700174.

After RC1

The OpenStack proposal bot will propose changes to the new branch and the master branch. These need to be approved.

After the stable branch has been cut, the master branch can be unfrozen and development on features for the next release can begin. At this point it will still be using dependencies and upper constraints from the release branch, so revert the patch created in update-dependencies-for-release. For example, see https://review.opendev.org/701747.

Finally, set the previous release used in upgrade jobs to the new release. For example, see https://review.opendev.org/709145.

RC2+

Further release candidates may be created on the stable branch as necessary in a similar manner to RC1.

Final Releases

A release candidate may be promoted to a final release if it has no critical bugs against it.

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

The changes should be proposed to the releases repository. For example: https://review.opendev.org/701724.

Post-release activites

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

Continuing Development

Search for TODOs in the codebases describing tasks to be performed during the next release cycle.

Stable Releases

Stable branch releases should be made periodically for each supported stable branch, no less than once every 45 days.

5.7 KiB Raw Blame History