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

8.3 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

    • this command is useful to list release notes added this cycle:

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

      Note

      Release notes for backported changes (i.e. already present in the previous, stable branch) will not show in the output.

    • example (kolla): https://review.opendev.org/648677/

    • example (kolla-ansible): https://review.opendev.org/648685/

  • 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.opendev.org/647819
  • update OPENSTACK_RELEASE variable in kolla/common/config.py
  • 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.

Note

Use the new-release tool for those activities.

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
  • revert the patch to switch OPENSTACK_RELEASE in kolla on the master branch
  • switch to use the new release of RDO on the new stable branch (master uses the delorean development packages)
  • switch to use the newly tagged container images (the branch for development mode on the new stable branch follows automatically since Victoria)
  • update previous release variables on master
  • search for TODOs/FIXMEs/NOTEs in the codebases describing tasks to be performed during the next release cycle
    • may include deprecations, code removal, etc.
    • these usually reference either the new cycle or the previous cycle; new cycle may be referenced using only the first letter (for example: V for Victoria).

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.

Stable Releases

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

Branch Lifecycle

The lifecycle of stable branches in OpenStack is described in the project team guide. The current status of each branch is published on the releases site.

Extended Maintenance (EM)

When a branch is entering EM, projects will make final releases. The release team will propose tagging the Kolla deliverables as EM, but this should only be done once all other dependent projects have made their final release, and final Kolla releases have been made including those dependencies.

After a branch enters EM, we typically do the following:

  • stop backporting fixes to the branch by default. Important fixes or those requested by community members may be merged if deemed appropriate
  • stop publishing images to Dockerhub
  • stop actively maintaining CI

End of Life (EOL)

Once a branch has been unmaintained (failing CI, no patches merged) for 6 months, it may be moved to EOL. Since this is done at different times for different projects, send an email to openstack-discuss to keep the community informed.