Release Processes

Release Processes

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

Before PTG (after closing previous release)

  1. Set up the release schedule for the newly opened cycle by creating the required pages in openstack/releases.
  2. Update the link to the documentation on the newly opened cycle page to point to the right place on docs.openstack.org.
  3. Create the $series-relmgt-plan and $series-relmgt-tracking etherpads.
  4. Use init-series to create stub deliverable files based on the contents of the previous release.

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 afternoon (US) or Friday morning (EU/APAC) with information needed about the following week (deadlines, instructions, etc.).
  5. The week before Milestone-1, include a reminder about completing the responses to community-wide goals in the countdown email.

Milestone-1

  1. Generate release requests for all cycle-with-intermediary libraries which had changes, but did not release since the previous release. That patch will be used as a base to communicate with the team: if a team wants to wait for a specific patch to make it to the library, someone from the team can -1 the patch to have it held, or update that patch with a different commit SHA.

  2. Run tools/aclissues.py to detect potential leftovers in Gerrit ACLs allowing official deliverables to directly tag or branch without going through openstack/releases. You need to specify the location of up-to-date checkouts for the governance and the project-config repositories. For example:

    tools/aclissues.py ../project-config ../governance
    

Between Milestone-1 and Milestone-2

  1. Use the countdown emails to list which projects have not done any stable release yet, to encourage them to do so.

  2. Use the countdown emails to list which intermediary-released (or independent) deliverables haven’t done a release yet. Remind teams that intermediary-released services that have not done a release by milestone-2 should be switched to the cycle-with-rc model.

    For this, run:

    tox -e venv -- list-deliverables --unreleased --model cycle-with-intermediary \
    --type client-library --type horizon-plugin --type library --type other
    
  3. Mention the upcoming MembershipFreeze deadline in the countdown emails.

  4. Ahead of MembershipFreeze, run membership_freeze_test to check for any new deliverable in governance that has not been released yet:

    tox -e membership_freeze_test -- $series ~/branches/governance/reference/projects.yaml
    

    Those should either get a release management exception (see release-management key in the governance projects.yaml file) or an empty deliverable file should be added to the series so that we can properly track it. Leftovers are considered too young to be released in the next release and will be reconsidered at the next cycle.

Milestone-2

  1. Generate release requests for all cycle-with-intermediary libraries which had changes, but did not release since milestone-1. That patch will be used as a base to communicate with the team: if a team wants to wait for a specific patch to make it to the library, someone from the team can -1 the patch to have it held, or update that patch with a different commit SHA.

  2. Run tools/aclissues.py to detect potential leftovers in Gerrit ACLs allowing official deliverables to directly tag or branch without going through openstack/releases. You need to specify the location of up-to-date checkouts for the governance and the project-config repositories. For example:

    tools/aclissues.py ../project-config ../governance
    

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. For intermediary-released service projects that have not done a release by milestone-2, propose a change from cycle-with-intermediary to cycle-with-rc. Engage with PTLs and release liaisons to either get an intermediary release, or a confirmation of the model switch.

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

    1. Run the command from milestone-2 again to get a list of libraries:

      tools/list_library_unreleased_changes.sh
      
    2. Include list of unreleased libraries in the email to increase visibility.

  4. Two weeks before Milestone-3, prepare other teams to the final release rush.

    1. Ask the release liaisons for the affected teams to update the contents of their $project-stable-maint groups, as that group will control the stable/$series branch prior to release. They should reach out to the stable-maint-core group for additions.
    2. Notify the Infrastructure team to generate an artifact signing key (but not replace the current one yet), and begin the attestation process.

Final Library Release (week before Milestone-3)

  1. Generate release requests for all cycle-with-intermediary libraries (except client libraries) which had changes, but did not release since milestone-2. That patch will be used as a base to communicate with the team: if a team wants to wait for a specific patch to make it to the library, someone from the team can -1 the patch to have it held, or update that patch with a different commit SHA.
  2. 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.
  3. Remind liaisons to prepare releases for client libraries at Milestone-3.
  4. Update the feature list and allowed stable branch names in devstack-gate for the new stable branch. For example, https://review.openstack.org/362435 and https://review.openstack.org/363084
  5. Allow the stable/$series branch to be requested with each library final release if they know they are ready. Do not require branching at this point in case of critical issues requiring another approved release past the freeze date.
  6. For stable libraries that did not have any change merged over the cycle, create a stable branch from the last available release.

Milestone-3

  1. Generate release requests for all client libraries which had changes, but did not release since milestone-2. That patch will be used as a base to communicate with the team: if a team wants to wait for a specific patch to make it to the library, someone from the team can -1 the patch to have it held, or update that patch with a different commit SHA.

  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. Allow the stable/$series branch to be requested with each client library final release if they know they are ready. Do not require branching at this point in case of critical issues requiring another approved release past the freeze date.

  4. Remind PTLs/liaisons that master should be frozen except for bug fixes and feature work with FFEs.

  5. Remind PTL/liaisons to start preparing “prelude” release notes as summaries of the content of the release so that those are merged before their first release candidate.

  6. Freeze all cycle-based library releases except for release-critical bugs. Independently-released libraries may still be released, but constraint or requirement changes will be held until after the freeze period.

  7. Include a reminder about completing the responses to community-wide goals in the countdown email.

  8. Run tools/aclissues.py to detect potential leftovers in Gerrit ACLs allowing official deliverables to directly tag or branch without going through openstack/releases. You need to specify the location of up-to-date checkouts for the governance and the project-config repositories. For example:

    tools/aclissues.py ../project-config ../governance
    
  9. Email openstack-discuss to give PTLs a heads up to start thinking about what they might want to include in their deliverables file as cycle-highlights and that RC1 is the deadline for them.

Between Milestone-3 and RC1

  1. Warn cycle-with-intermediary projects that have releases more than 2 months old that we will use their existing release as a point for branching if they have not prepared a newer release by the final RC deadline.

  2. Propose stable/$series branch creation for all client and non-client libraries that had not requested it at freeze time. The following command may be used:

    tox -e venv -- propose-library-branches --include-clients
    
  3. Include a reminder in the weekly countdown email reminding PTLs of the RC1 deadline for cycle-highlights.

RC1 week

  1. Early in the week, generate RC1 release requests (including the stable/$series branch creation) for all cycle-with-rc deliverables. That patch will be used as a base to communicate with the team: if a team wants to wait for a specific patch to make it to the RC, someone from the team can -1 the patch to have it held, or update that patch with a different commit SHA.

  2. Email openstack-discuss list to remind PTLs that cycle-highlights are due this week so that they can be included in release marketing preparations.

  3. By the end of the week, ideally we would want a +1 from the PTL and/or release liaison to indicate approval. However we will consider the absence of -1 or otherwise negative feedback as an indicator that the automatically proposed patches can be approved at the end of the RC deadline week.

  4. After the minimum set of projects used by devstack have been branched, the devstack branch can be created. Devstack doesn’t push a tag at RC1 it is just branched off of HEAD

  5. After devstack is branched a grenade branch can be created. As with devstack it will branch from HEAD instead of a tag.

  6. Update the default branch for devstack in the new stable branch. For example, https://review.openstack.org/#/c/493208/

  7. Update the grenade settings in devstack-gate for the new branch. For example, https://review.openstack.org/362438.

    Note

    As soon as grenade is updated for the new branch (see the RC1 instructions that follow), projects without stable branches may start seeing issues with their grenade jobs because without the stable branch the branch selection will cause the jobs to run master->master instead of previous->master. At the end of Ocata this caused trouble for the Ironic team, for example.

  8. For translations, create stable-$series versions in the Zanata translation server on https://translate.openstack.org for all projects that the translation team wants to handle. Create new translation-jobs-$series periodic jobs to import translations from the Zanata translation server and propose them to projects, add these jobs to all projects that have a stable-$series version.

    Note this work is done by translation team.

  9. After all cycle-with-rc projects have their branches created, someone from the requirements core team (preferably the requirements PTL) needs to propose an update the deliverable file to create the stable/$series branch for openstack/requirements. Then announce that the requirements freeze is lifted from master.

    Note

    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.

  10. In the tempest repo, create new branch specific jobs for our two branchless projects, devstack-gate and tempest. Configure tempest to run them on all changes, voting. Configure tempest to run them as periodic bitrot jobs as well. All this can be done in one tempest patch, like for example, see https://review.openstack.org/521888. Configure devstack-gate to run the new jobs in check pipeline only, non-voting, for example see https://review.openstack.org/545144.

  11. Add the new branch to the list of branches in the periodic-stable job templates in openstack-zuul-jobs. For example, see https://review.openstack.org/545268/.

Between RC1 and Final

  1. In the countdown email, remind everyone that the latest RC (for cycle-with-rc deliverables) or the latest intermediary release (for cycle-with-intermediary deliverables) will automatically be used as the final $series release on release day.

  2. Let cycle-with-rc projects iterate on RCs as needed. The final release candidate for each project needs to be prepared at least one week before the final release date.

    Note

    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. Teams that know they will need additional release candidates can submit the requests and mark them WIP until actually ready, so the release team knows that more candidates are coming.

  3. Ensure that all projects that are publishing release notes have the notes link included in their deliverable file. See tools/add_release_note_links.sh.

  4. Encourage liaisons to merge all translation patches.

  5. When all translations and bug fixes are merged for a project, prepare a new release candidate.

  6. After final releases for release:cycle-with-intermediary projects are tagged, create their stable branches.

  7. On the morning of the deadline for final release candidates, check the list of unreleased changes for milestone projects and verify with the PTLs and liaisons that they are planning a release or that they do not need one.

    In the release-tools repository working directory, run:

    $ ./list_unreleased_changes.sh stable/newton $(list-repos --tag release:cycle-with-rc) 2>&1 | tee unreleased.log
    
  8. Propose stable/$series branch creation for deliverables that have not requested it yet.

  9. As soon as the last release candidate is tagged and the freeze period is entered, use propose-final-releases to tag the existing most recent release candidates as the final release for projects using the cycle-with-rc model.

  10. Ask liaisons and PTLs of milestone-based projects to review and +1 the final release proposal from the previous step so their approval is included in the metadata that goes onto the signed tag.

  11. The week before final release test the release process using the openstack/release-test repository.

  12. Notify the documentation team that it should be safe to apply their process to create the new release series landing pages for docs.openstack.org. Their process works better if they wait until most of the projects have their stable branches created, but they can do the work before the final release date to avoid having to synchronize with the release team on that day.

Final Release

  1. Approve the final release patch created earlier.

  2. Run the missing-releases script to check for missing tarballs on the release page before the announcement:

    tox -e venv -- missing-releases --series $SERIES
    
  3. Mark series as released on releases.o.o, by updating doc/source/index.rst and doc/source/$series/index.rst. See https://review.openstack.org/#/c/381006 for an example.

  4. Update the default series name in openstack/releases/openstack_releases/defaults.py to use the new series name.

  5. Send release announcement email to openstack-announce@lists.openstack.org, based on templates/final.txt. Coordinate the timing of the email with the press release from the Foundation staff.

  6. Send an email to the openstack-dev list to point to the official release announcement, and declare openstack/releases unfrozen for releases on the new series.

Post-Final Release

  1. The week after the final release, process any late or blocked release requests for deliverables for any branch (treating the new series branch as stable).

cycle-trailing Final Release

  1. A week before the cycle-trailing deadline, use propose-final-releases --all to tag the existing most recent release candidates as the final release for the cycle-trailing projects.
  2. Ask liaisons and PTLs of cycle-trailing projects to review and +1 the final release proposal from the previous step so their approval is included in the metadata that goes onto the signed tag.
  3. On the cycle-trailing deadline approve the final release patch created earlier.
Creative Commons Attribution 3.0 License

Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.