Chronological Release Liaison Guide

This is a reference guide that a release liaison may use as an aid, if they choose.

Watcher uses the Distributed Project Leadership (DPL) model where traditional release liaison responsibilities are distributed among various liaisons. The release liaison is responsible for requesting releases, reviewing Feature Freeze Exception (FFE) requests, and coordinating release-related activities with the team.

How to Use This Guide

This guide is organized chronologically to follow the OpenStack release cycle from PTG planning through post-release activities. You can use it in two ways:

For New Release Liaisons

Read through the entire guide to understand the full release cycle, then bookmark it for reference during your term.

For Experienced Release Liaisons

Jump directly to the relevant section for your current phase in the release cycle. Each major section corresponds to a specific time period.

Key Navigation Tips

  • The Glossary defines all acronyms and terminology used

  • Time-sensitive activities are clearly marked by milestone phases

  • DPL coordination notes indicate when team collaboration is required

DPL Liaison Coordination

Under the DPL model, the release liaison coordinates with other project liaisons and the broader team for effective release management. The release liaison has authority for release-specific decisions (FFE approvals, release timing, etc.) while major process changes and strategic decisions require team consensus.

This coordination approach ensures that:

  • Release activities are properly managed by a dedicated liaison

  • Team input is gathered for significant decisions

  • Other liaisons are informed of release-related developments that may affect their areas

  • Release processes remain responsive while maintaining team alignment

Project Context

Watcher Main Repository

Primary codebase for the Watcher service

Watcher Dashboard

Horizon plugin for Watcher UI

Watcher Tempest Plugin

Integration tests (follows tempest cycle)

Python Watcher Client

Command-line client and Python library

Watcher Specifications

Design specifications (not released)

Watcher Launchpad (Main)

Primary bug and feature tracking

Watcher Dashboard Launchpad

Dashboard-specific tracking

Watcher Tempest Plugin Launchpad

Test plugin tracking

Python Watcher Client Launchpad

Client library tracking

Project Team Gathering

Event Liaison Coordination

  • Work with the project team to select an event liaison for PTG coordination. The event liaison is responsible for:

    • Reserving sufficient space at PTG for the project team’s meetings

    • Putting out an agenda for team meetings

    • Ensuring meetings are organized and facilitated

    • Documenting meeting results

  • If no event liaison is selected, these duties revert to the release liaison.

  • Monitor for OpenStack Events team queries on the mailing list requesting event liaison volunteers - teams not responding may lose event representation.

PTG Planning and Execution

  • Create PTG planning etherpad, retrospective etherpad and alert about it in watcher meeting and dev mailing list

  • Run sessions at the PTG (if no event liaison is selected)

  • Do a retro of the previous cycle

  • Coordinate with team to establish agreement on the agenda for this release:

Review Days Planning

Determine number of review days allocated for specs and implementation work

Freeze Dates Coordination

Define Spec approval and Feature freeze dates through team collaboration

Release Schedule Modifications

Modify the OpenStack release schedule if needed by proposing new dates (Example: https://review.opendev.org/c/openstack/releases/+/877094)

  • Sign up for group photo at the PTG (if applicable)

After PTG

  • Send PTG session summaries to the dev mailing list

  • Add RFE bugs if you have action items that are simple to do but without a owner yet.

  • Update IRC #openstack-watcher channel topic to point to new development-planning etherpad.

A few weeks before milestone 1

Milestone 1

  • Release watcher and python-watcherclient via the openstack/releases repo. Watcher follows the cycle-with-intermediary release model:

  • Create actual releases (not just launchpad bookkeeping) at milestone points

  • No launchpad milestone releases are created for intermediary releases

  • When releasing the first version of a library for the cycle, bump the minor version to leave room for future stable branch releases

  • Release stable branches of watcher

Stable Branch Release Process

Prepare the stable branch for evaluation:

git checkout <stable branch>
git log --no-merges <last tag>..

Analyze commits to determine version bump according to semantic versioning.

Semantic Versioning Guidelines

Choose version bump based on changes since last release:

Major Version (X)

Backward-incompatible changes that break existing APIs

Minor Version (Y)

New features that maintain backward compatibility

Patch Version (Z)

Bug fixes that maintain backward compatibility

Release Command Usage

Generate the release using OpenStack tooling:

  • Use the new-release command

  • Propose the release with version according to chosen semver format (x.y.z)

Summit

Responsibility Precedence for Summit Activities:

  1. Project Update/Onboarding Liaisons (if appointed):

    • Project Update Liaison: responsible for giving the project update showcasing team’s achievements for the cycle to the community

    • Project Onboarding Liaison: responsible for giving/facilitating onboarding sessions during events for the project’s community

  2. Event Liaison (if no Project Update/Onboarding liaisons exist):

    • Coordinates all Summit activities including project updates and onboarding

  3. Release Liaison (if no Event Liaison is appointed):

    • Work with the team to ensure Summit activities are properly handled:

      • Prepare the project update presentation

      • Prepare the on-boarding session materials

      • Prepare the operator meet-and-greet session

Note

The team can choose to not have a Summit presence if desired.

A few weeks before milestone 2

  • Plan a spec review day (optional)

Milestone 2

  • Spec freeze (unless changed by team agreement at PTG)

  • Release watcher and python-watcherclient (if needed)

  • Stable branch releases of watcher

Shortly after spec freeze

  • Create a blueprint status etherpad to help track, especially non-priority blueprint work, to help things get done by Feature Freeze (FF). Example:

  • Create or review a patch to add the next release’s specs directory so people can propose specs for next release after spec freeze for current release

Milestone 3

  • Feature freeze day

  • Client library freeze, release python-watcherclient

  • Close out all blueprints, including “catch all” blueprints like mox, versioned notifications

  • Stable branch releases of watcher

  • Start writing the cycle highlights

Week following milestone 3

  • If warranted, announce the FFE (feature freeze exception process) to have people propose FFE requests to a special etherpad where they will be reviewed. FFE requests should first be discussed in the IRC meeting with the requester present. The release liaison has final decision on granting exceptions.

    Note

    if there is only a short time between FF and RC1 (lately it’s been 2 weeks), then the only likely candidates will be low-risk things that are almost done. In general Feature Freeze exceptions should not be granted, instead features should be deferred and reproposed for the next development cycle. FFE never extend beyond RC1.

  • Mark the max microversion for the release in the REST API Version History

A few weeks before RC

  • Update the release status etherpad with RC1 todos and keep track of them in meetings

  • Go through the bug list and identify any rc-potential bugs and tag them

RC

Immediately after RC

  • Look for bot proposed changes to reno and stable/<cycle>

  • Create the launchpad series for the next cycle

  • Set the development focus of the project to the new cycle series

  • Set the status of the new series to “active development”

  • Set the last series status to “current stable branch release”

  • Set the previous to last series status to “supported”

  • Repeat launchpad steps ^ for all watcher deliverables.

  • Make sure the specs directory for the next cycle gets created so people can start proposing new specs

  • Make sure to move implemented specs from the previous release

    • Move implemented specs manually (TODO: add tox command in future)

    • Remove template files:

      rm doc/source/specs/<release>/index.rst
rm doc/source/specs/<release>/template.rst

  • Ensure liaison handoff: either transition to new release liaison or confirm reappointment for next cycle

Glossary

DPL

Distributed Project Leadership - A governance model where traditional PTL responsibilities are distributed among various specialized liaisons.

FFE

Feature Freeze Exception - A request to add a feature after the feature freeze deadline. Should be used sparingly for low-risk, nearly complete features.

GA

General Availability - The final release of a software version for production use.

PTG

Project Team Gathering - A collaborative event where OpenStack project teams meet to plan and coordinate development activities.

RC

Release Candidate - A pre-release version that is potentially the final version, pending testing and bug fixes.

RFE

Request for Enhancement - A type of bug report requesting a new feature or enhancement to existing functionality.

SLURP

Skip Level Upgrade Release Process - An extended maintenance release that allows skipping intermediate versions during upgrades.

Summit

OpenStack Summit - A conference where the OpenStack community gathers for presentations, discussions, and project updates.

Miscellaneous Notes

How to track launchpad blueprint approvals

Core team approves blueprints through team consensus. The release liaison ensures launchpad status is updated correctly after core team approval:

  • Set the approver as the core team member who approved the spec

  • Set the Direction => Approved and Definition => Approved and make sure the Series goal is set to the current release. If code is already proposed, set Implementation => Needs Code Review

  • Optional: add a comment to the Whiteboard explaining the approval, with a date (launchpad does not record approval dates). For example: “We discussed this in the team meeting and agreed to approve this for <release>. – <nick> <YYYYMMDD>”

How to complete a launchpad blueprint

  • Set Implementation => Implemented. The completion date will be recorded by launchpad