releases/PROCESS.rst

Release Processes

This document describes the relative ordering and rough timeline for all of the steps related to preparing the release.

Before Summit (after closing prevous release)

1. Set up the release schedule for the newly opened cycle by creating the required pages in openstack/releases.
2. Create the $series-relmgt-plan and $series-relmgt-tracking etherpads.

Between Summit and Milestone-1

1. Establish liaisons by having them update https://wiki.openstack.org/wiki/CrossProjectLiaisons with their contact information.
2. Email PTLs directly one time to explain the use of the "[release]" email tag on the openstack-dev list.
3. Encourage liaisons to ensure that their release model is set properly before the first milestone.
4. Start weekly countdown emails, sent on Thursday with information needed about the following week (deadlines, instructions, etc.).

Milestone-1

1. Include the deadline for the milestone in the countdown emails but do not send extra reminders to liaisons. Missing the first milestone isn't important in terms of the release, so we want to encourage everyone to pay attention on their own.

Between Milestone-1 and Milestone-2

1. Follow up with PTLs and liaisons for projects that missed the first milestone.
2. The week before Milestone-2 include a reminder of the deadline in the countdown emails. Also remind release:independent and release:cycle-with-intermediary projects to prepare releases.

Milestone-2

n/a

Between Milestone-2 and Milestone-3

1. In the countdown email immediately after Milestone-2, include a reminder about the various freezes that happen around Milestone-3.

2. Two weeks before Milestone-3, include a reminder about the final library release freeze coming the week before Milestone-3.

3. Two weeks before Milestone-3, set up the gerrit ACLs for the yet-to-be-created stable/$series branches.

   (The timing for this is meant to postpone it until all projects that will be included in the current release are accepted but not put it off for so long that we have to rush to merge the changes in order to avoid having the release blocked.)

   1. Update ACLs for refs/heads/stable/$series so that members of $project-new-branch can approve changes.
   2. Set the population of all $project-new-branch groups to the "Release Managers" group and $project-ptl.

Final Library Release (week before Milestone-3)

1. Release libraries as quickly as possible this week to ensure they are all done before the freeze. Consider relaxing the "not on Friday" release rule if absolutely necessary.
2. Remind liaisons to prepare releases for client libraries at Milestone-3.
3. Create stable/$series branches for the libraries after their final release is prepared using branch_from_yaml.sh.

Milestone-3

1. Verify that all projects following release:cycle-with-intermediary have prepared at least one release for the cycle.
2. Freeze changes to openstack/requirements by applying -2 to all open patches. Ensure that reviewers do not approve changes created by the proposal bot.
3. Create stable/$series branches for the client libraries after their final release is prepared using branch_from_yaml.sh.
4. Remind PTLs/liaisons that master should be frozen except for bug fixes and feature work with FFEs.
5. Freeze all library releases except for release-critical bugs.

Between Milestone-3 and RC1

1. Encourage liaisons to wait as long as possible to create RC1 to avoid immediately having to create an RC2 with a new bug fix.
2. Use the dashboard command to prepare the data for tracking the final release and import it into a Google Docs spreadsheet for collaborative editing and monitoring.

RC1

1. Create stable/$series branches for projects after their RC1 is tagged using branch_from_yaml.sh.

2. After all cycle-with-milestone projects have their branches created, use make_stable_branch.sh to create the stable/$series branch for openstack/requirements. Then announce that the requirements freeze is lifted from master.

   Note that we wait until after the other projects have branched to create the branch for requirements because tests for the stable branches of those projects will fall back to using the master branch of requirements until the same stable branch is created, but if the branch for the requirements repo exists early the changes happening in master on the other projects will not use it and we can have divergence between the requirements being tested and being declared as correct.

Between RC1 and Final

Try to avoid creating more than 3 release candidates so we are not creating candidates that consumers are then trained to ignore. Each release candidate should be kept for at least 1 day, so if there is a proposal to create RCX but clearly a reason to create another one, delay RCX to include the additional patches.

1. Encourage liaisons to merge all translation patches.
2. When all translations and bug fixes are merged for a project, prepare a new release candidate.
3. Ensure that the final release candidate for each project is prepared at least one week before the final release date.

Final Release

1. Use propose-final-releases to tag the existing most recent release candidates as the final release for projects using the cycle-with-milestone model
2. Reset gerrit ACLs
   1. Update all of the $project-new-branch groups to have $project-stable-maint as members instead of "Release Managers".
   2. Remove the refs/heads/stable/$series from the project gerrit ACLs.