v1.20.0 release

[joestringer]

Setup preparation

• Ensure Docker is installed and running
• Ensure a setup is in place for signing tags with Git (GPG, SSH, S/MIME)
• Install gh.
• Make sure the [release][Cilium release-notes tool] repository is installed
  locally:
  • Run git clone https://github.com/cilium/release.git "$GOPATH/src/github.com/cilium/release"
• Make sure the release binary is up to date:
  git checkout master && git pull && make
• Read the documentation of release start --help tool to understand what
  each automated step does.

Pre-check (run ~1 week before targeted publish date)

• When you create a GitHub issue using this issue template, GitHub Slack app posts a
  message in #launchpad Slack channel. Create a thread for that message and ping the
  current backporter to merge the outstanding backport PRs and stop merging any new
  backport PRs until the GitHub issue is closed (to avoid generating incomplete
  release notes).
• Run ./release start --steps 1-pre-check --target-version v1.20.0
  • Check that there are no release blockers for the targeted release
    version.
  • Ensure that outstanding backport PRs are merged (these may be
    skipped on case by case basis in coordination with the backporter).

Preparation PR (run ~1 day before targeted publish date. This step can be re-run multiple times.)

• Run ./release start --steps 2-prepare-release --target-version v1.20.0
• Manually fix the following:
  • Add the 'stable' tag as part of the GitHub workflow and remove the
    'stable' tag from the last stable branch (v1.19).
• Manually submit a PR that removes the 'stable' tag from the last stable
  branch.
• Merge PR Prepare for release v1.20.0 cilium#47566

Tagging

• Ask a maintainer if there are any known issues that should hold up the release
• Run ./release start --steps 3-tag --target-version v1.20.0
• Ask a maintainer to approve the build in the following link (keep the URL
  of the GitHub run to be used later):
  Cilium Image Release builds

Post Tagging (run after docker images are published. In case of failure, this step can be re-run multiple times.)

• Check if the image build process was successful and check the PR opened
  by the Release bot. If the PR was not opened, you can safely re-run the failed job.
• Merge PR

Publish helm (run after docker images are published. In case of failure, this step can be re-run multiple times.)

• Ask a maintainer to approve the release-helm deployment in the GitHub
  URL of the run kept from the "Tagging" step. (Cilium Image Release builds)
• Check if the image build process was successful and check if the helm
  chart was published by the Release bot under the Cilium helm charts.
  If that did not happen, you can safely re-run the failed job.
• Open Cilium helm Chart Workflow and check if the
  workflow run is successful for v1.20.0.

Publish docs

• Check read the docs configuration:
  • Set a new build as active and hidden in active versions.
  • Set the default version and mark the EOL version as active, and
    hidden and configure the new minor version as active and not
    hidden in active versions.
  • Deactivate previous RCs.

Post-release

• Check draft release from releases page
  • Update the text at the top with 2-3 highlights of the release
  • Check with @cilium/security if the release addresses any open security
    advisory. If it does, include the list of security advisories at the
    top of the release notes.
  • Check if the GitHub release page with the options:
    Set as the latest release and Create a discussion for this release in
    the "Announcements" category.
  • Publish the release
• Announce the release in #general on Slack (Use [@]channel for v1.20.0)
• For new minor version update security policy
• Prepare post-release changes to main branch using ../release/internal/bump-readme.sh.
  • echo v1.20.0 > stable.txt.
  • echo '{"results":[{"slug":"v1.20"}]}' > Documentation/_static/stable-version.json.
  • Commit / amend the commit to add all of the changes above and push the PR.
  • Merge the post-release PR.
• Update the upgrade guide and roadmap on the main branch to prepare
  for the next development cycle. References to v1.20 should be removed, but
  the upgrade guide structure should remain in place in order for
  developers to document the changes necessary for the next release.
• The oldest maintained release branch will now no longer be maintained.
  Prepare an update PR for the main branch to remove references to that
  branch. This may involve modifying documentation, code comments and
  configuration for GitHub or Renovate.
  - git grep v1.18
• Update the Cilium Wikipedia release timeline table to reflect the new
  version. Ensure the version, release date, and any notable changes are
  accurately represented in the table and graph.
• Add release-blocker labels for the two upcoming minor release versions.
  • Update the release-blocker project automation to auto-add issues to
    the project when the issue is labeled with a release-blocker label.