openstack
/
kolla
Code Issues Proposed changes
kolla/doc/source/contributor/release-management.rst

6.0 KiB
Raw Blame History

Release Management

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, Kolla's release model differs from many other OpenStack projects. Kolla 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.

Launchpad Admin

We track series (e.g. Stein) and milestones (e.g. stein-1) on Launchpad, and target bugs and blueprints to these. Populating these in advance is necessary. This needs to be done for each of the following projects:

At the beginning of a cycle, ensure a named series exists for the cycle in each project. If not, create one via the project landing page (e.g. https://launchpad.net/kolla) - in the "Series and milestones" section click in "Register a series". Once the series has been created, create the necessary milestones, including the final release. Series can be marked as "Active Development" or "Current Stable Release" as necessary.

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, Kolla 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:

  • test the code and fix (at a minimum) all critical bugs
  • the release notes for each project should be tidied up
  • mark bugs on Launchpad with the correct milestone
    • this command is useful to check for commits that fixed bugs:
      • git log origin/stable/<previous release>..origin/master | grep -i Closes-Bug
  • update dependencies for source images on master to use release candidates:
    • ./tools/version-check.py --openstack-release $SERIES
    • this will only work when release candidates have been created for the dependent projects
    • add --include-independent to update projects with an independent release cycle
    • example (kolla): https://review.openstack.org/647819
  • add cycle highlights when requested by the release team

RC1

RC1 is the first release candidate, and also marks the point at which the stable branch is cut.

After RC1

  • approve bot-proposed patches to master and the new stable branch
  • revert the patch to use release candidates of dependencies on the master branch
  • switch to use the new release of RDO on the new stable branch (master uses the delorean development packages)
  • update previous release variables on master
  • search for TODOs in the codebases describing tasks to be performed during the next release cycle
    • may include deprecations, code removal, etc.

After OpenStack Final Release

  • update dependencies for source images on master to use final releases:

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.

  • create final release by submitting patches to the releases repository
    • example (kolla): TODO
    • example (kolla-ansible): TODO

Stable Releases

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