openstack
/
kayobe
Code Issues Proposed changes

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
This commit is contained in:
Mark Goddard 2020-02-21 15:01:42 +00:00 committed by Pierre Riteau
parent cdc1d5ada2
commit 6e1def534c
1 changed files with 99 additions and 70 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

169
doc/source/development/releases.rst
View File

@ -2,21 +2,60 @@
Releases Releases
======== ========
The `project creator's guide This guide is intended to complement the `OpenStack releases site
<https://docs.openstack.org/infra/manual/drivers.html#release-management>`__ <https://releases.openstack.org/>`__, and the project team guide's section on
provides information on release management. As Kayobe is not an official `release management
project, it cannot use the official release tooling in the <https://docs.openstack.org/project-team-guide/release-management.html>`__.
``openstack/releases`` repository.
There are various `useful files Team members make themselves familiar with the release schedule for the current
<http://opendev.org/openstack-infra/project-config/src/branch/master/roles/copy-release-tools-scripts/files/release-tools/>`__ release, for example https://releases.openstack.org/train/schedule.html.
in the ``openstack-infra/project-config`` repository. In particular, see the
``release.sh`` and ``make_branch.sh`` scripts.
.. _releases-preparing-for-a-release: Release Model
=============
Preparing for a release As a deployment project, Kayobe's release model differs from many other
======================= OpenStack projects. Kayobe follows the `cycle-trailing
<https://docs.openstack.org/project-team-guide/release-management.html#trailing-the-common-cycle>`__
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-for-release:
Update dependencies to upcoming release Update dependencies to upcoming release
--------------------------------------- ---------------------------------------
@ -25,7 +64,7 @@ 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, 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 following the introduction of the ``openstack_release`` variable. This is done
prior to creating a release candidate. For example, see prior to creating a release candidate. For example, see
https://review.opendev.org/#/c/652091. https://review.opendev.org/#/c/694616/.
Synchronise kayobe-config Synchronise kayobe-config
------------------------- -------------------------
@ -49,14 +88,20 @@ suit you and be careful not to lose any configuration.
Commit the changes and submit for review. Commit the changes and submit for review.
Add a prelude to release notes Prepare release notes
------------------------------ ---------------------
It's possible to add a prelude to the release notes for a particular release It's possible to add a prelude to the release notes for a particular release
using a ``prelude`` section in a ``reno`` note. using a ``prelude`` section in a ``reno`` note.
Creating a release candidate 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 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 release candidate. This allows the ``reno`` tool to determine where to stop
@ -64,67 +109,48 @@ 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 following form: ``<release tag>.0rc$n``, where ``$n`` is the release candidate
number. number.
The ``tools/release.sh`` script in the ``kayobe`` repository can be used to tag This should be done for each deliverable using the `releases
a release and push it to Gerrit. For example, to tag and release the ``kayobe`` <https://opendev.org/openstack/releases>`_ tooling. A release candidate and
deliverable release candidate ``4.0.0.0rc1`` in the Queens series from the base stable branch defintitions should be added for each Kayobe deliverable
of the ``stable/queens`` branch: (``kayobe``, ``kayobe-config``, ``kayobe-config-dev``). These are defined in
``deliverables/<release name>/kayobe.yaml``. Currently the same version is used
for each deliverable.
.. code-block:: console The changes should be proposed to the releases repository. For example:
https://review.opendev.org/#/c/700174.
./tools/release.sh kayobe 4.0.0.0rc1 origin/master queens After RC1
=========
Creating a stable branch The OpenStack proposal bot will propose changes to the new branch and the
======================== master branch. These need to be approved.
Stable branches should be cut for each Kayobe deliverable (``kayobe``, After the stable branch has been cut, the master branch can be unfrozen and
``kayobe-config``, ``kayobe-config-dev``). 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 :ref:`update-dependencies-for-release`. For
example, see https://review.opendev.org/701747.
To create a branch ``<new branch>`` at commit ``<ref>``: Finally, set the previous release used in upgrade jobs to the new release. For
example, see https://review.opendev.org/709145.
.. code-block:: console RC2+
====
cd /path/to/repo Further release candidates may be created on the stable branch as necessary in
git checkout -b <new branch> <ref> a similar manner to RC1.
git review -s
git push gerrit <new branch>
After creating the branch, on the new branch: Final Releases
==============
* update the ``.gitreview`` file on the new branch, for example: A release candidate may be promoted to a final release if it has no critical
https://review.openstack.org/609735 bugs against it.
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``, Tags should be created for each deliverable (``kayobe``, ``kayobe-config``,
``kayobe-config-dev``). Currently the same version is used for each. ``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 The changes should be proposed to the releases repository. For example:
a release and push it to Gerrit. For example, to tag and release the ``kayobe`` https://review.opendev.org/701724.
deliverable version ``4.0.0`` in the Queens series from the tip of the
``stable/queens`` branch:
.. code-block:: console
./tools/release.sh kayobe 4.0.0 origin/stable/queens queens
Post-release activites Post-release activites
---------------------- ----------------------
@ -135,8 +161,11 @@ release.
Continuing Development Continuing Development
====================== ======================
After the stable branch has been cut, the master branch can be unfrozen and Search for TODOs in the codebases describing tasks to be performed during the
development on features for the next release can begin. At this point it will next release cycle.
still be using dependencies and upper constraints from the release branch, so
revert the patch created in :ref:`releases-preparing-for-a-release`. For Stable Releases
example, see https://review.opendev.org/676941. ===============
Stable branch releases should be made periodically for each supported stable
branch, no less than once every 45 days.