Chronological PTL guide¶
This is just a reference guide that a PTL may use as an aid, if they choose.
New PTL¶
Update the nova meeting chair
Update the team wiki
Get acquainted with the release schedule
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
Have a priorities discussion at the PTG
Sign up for group photo at the PTG (if applicable)
Open review runways for the cycle
After PTG¶
Send PTG session summaries to the dev mailing list
Make sure the cycle priorities spec gets reviewed and merged
Run the count-blueprints script daily to gather data for the cycle burndown chart
A few weeks before milestone 1¶
Plan a spec review day
Periodically check the series goals others have proposed in the “Set series goals” link:
Milestone 1¶
Do milestone release of nova and python-novaclient (in launchpad only)
This is launchpad bookkeeping only. With the latest release team changes, projects no longer do milestone releases. See: https://releases.openstack.org/reference/release_models.html#cycle-with-milestones-legacy
For nova, set the launchpad milestone release as “released” with the date
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
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
Summit¶
Prepare the project update presentation. Enlist help of others
Prepare the on-boarding session materials. Enlist help of others
A few weeks before milestone 2¶
Plan a spec review day (optional)
Periodically check the series goals others have proposed in the “Set series goals” link:
Milestone 2¶
Spec freeze
Release nova and python-novaclient
Release other libraries as needed
Stable branch releases of nova
For nova, set the launchpad milestone release as “released” with the date
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
Milestone 3¶
Feature freeze day
Client library freeze, release python-novaclient
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
Write the cycle highlights
Week following milestone 3¶
Consider announcing the FFE (feature freeze exception process) to have people propose FFE requests to a special etherpad where they will be reviewed and possibly sponsored:
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
Mark the max microversion for the release in the REST API Version History:
A few weeks before RC¶
Make a RC1 todos etherpad and tag bugs as
<release>-rc-potentialand keep track of them, example:Go through the bug list and identify any rc-potential bugs and tag them
RC¶
Do steps described on the release checklist wiki:
If we want to drop backward-compat RPC code, we have to do a major RPC version bump and coordinate it just before the major release:
“Merge latest translations” means translation patches
Check for translations with:
Should NOT plan to have more than one RC if possible. RC2 should only happen if there was a mistake and something was missed for RC, or a new regression was discovered
Do the RPC version aliases just before RC1 if no further RCs are planned. Else do them at RC2. In the past, we used to update all service version aliases (example: https://review.opendev.org/230132) but since we really only support compute being backlevel/old during a rolling upgrade, we only need to update the compute service alias, see related IRC discussion: http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2018-08-08.log.html#t2018-08-08T17:13:45
Example: https://review.opendev.org/642599
More detail on how version aliases work: https://docs.openstack.org/nova/latest/configuration/config.html#upgrade-levels
Write the reno prelude for the release GA
Example: https://review.opendev.org/644412
Write the cycle-highlights in marketing-friendly sentences and propose to the openstack/releases repo. Usually based on reno prelude but made more readable and friendly
Example: https://review.opendev.org/644697
Immediately after RC¶
Look for bot proposed changes to reno and stable/<cycle>
Follow the post-release checklist
Add database migration placeholders
Example: https://review.opendev.org/650964
Drop old RPC compat code (if there was a RPC major version bump)
Example: https://review.opendev.org/543580
Bump the oldest supported compute service version
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
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.rstAlso 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
