Setup preparation

• Depending on your OS, make sure Docker is running
• Export a GITHUB_TOKEN that has access to the repository. Only classic tokens are
  [supported at the moment][GitHub PAT tracker], the needed scopes are write:org, public_repo and project.
• Make sure a setup (GPG, SSH, S/MIME) is in place for [signing tags]
  with Git and install gh.
• Make sure the [Cilium helm charts][Cilium charts] and [release][Cilium release-notes tool] repositories are installed locally:
  • Run git clone https://github.com/cilium/charts.git "$GOPATH/src/github.com/cilium/charts"
  • Run git clone https://github.com/cilium/release.git "$GOPATH/src/github.com/cilium/release"

    • If you already have the repo checked out, 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 release 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.15.10
  • 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).
  • Check with @cilium/security team in case there are any CVEs found in the
    docker image.
  • Check with @cilium/security team if there are any security fixes to
    include in the release.

Preparation PR (run ~1 day before release date. It can be re-run multiple times.)

• Go to [release workflow] and Run the workflow from "Branch: main", for
  step "2-prepare-release" and version for v1.15.10
  • Check if the workflow was successful and check the PR opened by the
    Release bot.
• Merge PR

Tagging

• Ask a maintainer if there are any known issues that should hold up the release
• FYI, do not wait too much time between a tag is created and the helm charts are published.
  Once the tags are published the documentation will be pointing to them. Until we release
  the helm chart, users will face issues while trying out our documentation.
• Run ./release start --steps 3-tag --target-version v1.15.10
• 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)

• Go to [release workflow] and Run the workflow from "Branch: main", for
  step "4-post-release" and version for v1.15.10
  • Check if the workflow was successful and check the PR opened by the
    Release bot.
• Merge PR

Publish helm (run after docker images are published)

• Update helm charts ./release start --steps 5-publish-helm --target-version v1.15.10
• Open [Charts Workflow] and check if the workflow run is successful.

Publish docs (only for pre/rc releases)

• Check [read the docs] configuration:
  • Set a new build as active and hidden in [active versions].
  • Deactivate previous RCs.
  • Update algolia configuration search in [docsearch-scraper-webhook].
    • Update the versions in docsearch.config.json, commit them and push a
      trigger the workflow here

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 whether the new release should be set as the latest release
    (via the checkbox at the bottom of the page). It should be the new
    latest if the version number is strictly superior to the current
    latest release displayed on GitHub (e.g. 1.11.13 does not become the
    new latest release over 1.12.5, but version 1.12.6 will).
  • Publish the release
• Announce the release in #general on Slack (do not use [@]channel).
  See below for templates.
• Prepare post-release changes to main branch using ../release/internal/bump-readme.sh.