Chronological PTL guide

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


Project Team Gathering

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

  • Run sessions at the PTG

  • Do a retro of the previous cycle

  • Make agreement on the agenda for this release, including but not exhaustively:

  • Discuss the implications of the SLURP or non-SLURP current release

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

A few weeks before milestone 1

Milestone 1

  • Do milestone release of nova and python-novaclient (in launchpad only, can be optional)

  • Release other libraries if there are significant enough changes since last release. When releasing the first version of a library for the cycle, bump the minor version to leave room for future stable branch releases

    • os-vif

    • placement

    • os-traits / os-resource-classes

  • Release stable branches of nova

    • git checkout <stable branch>

    • git log --no-merges <last tag>..

      • Examine commits that will go into the release and use it to decide whether the release is a major, minor, or revision bump according to semver

    • Then, propose the release with version according to semver x.y.z

      • X - backward-incompatible changes

      • Y - features

      • Z - bug fixes

    • Use the new-release command to generate the release


  • Prepare the project update presentation. Enlist help of others

  • Prepare the on-boarding session materials. Enlist help of others

  • Prepare the operator meet-and-greet session. Enlist help of others

A few weeks before milestone 2

  • Plan a spec review day (optional)

Milestone 2

  • Spec freeze (if agreed)

  • Release nova and python-novaclient (if new features were merged)

  • Release other libraries as needed

  • Stable branch releases of nova

  • For nova, set the launchpad milestone release as “released” with the date (can be optional)

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

Non-client library release freeze

  • Final release for os-vif

  • Final release for os-traits

  • Final release for os-resource-classes

Milestone 3

  • Feature freeze day

  • Client library freeze, release python-novaclient and osc-placement

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

  • Stable branch releases of nova

  • For nova, set the launchpad milestone release as “released” with the date

  • Start writing the cycle highlights

Week following milestone 3

A few weeks before RC


Immediately after RC

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

  • Follow the post-release checklist

  • 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 python-novaclient (optional)

  • Repeat launchpad steps ^ for placement

  • Register milestones in launchpad for the new cycle based on the new cycle release schedule

  • 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

    • Use tox -e move-implemented-specs <release>

    • Also remove template from doc/source/specs/<release>/index.rst

    • Also delete template file doc/source/specs/<release>/template.rst

  • Create new release wiki:

  • Update the contributor guide for the new cycle

Miscellaneous Notes

How to approve a launchpad blueprint

  • Set the approver as the person who +W the spec, or set to self if it’s specless

  • 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

  • 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