Release 2.11

[leizor]

Publish the release candidate

• Begin drafting the release notes
  • Create the release notes PR targeting the main branch
  • This step shouldn't block from publishing release candidate
  • After the release notes PR is merged (which usually happen after RC is published), cherry-pick them into the release branch
• Wait for any open PR we want to get merged before cutting the release candidate
  • We shouldn't wait for the open PRs beyond the scheduled release date
  • Eventually open a PR for every experimental feature we want to promote to stable
  • Eventually open a PR to remove any deprecated feature or configuration option that should be removed in this release
• Update CHANGELOG.md
  • Run ./tools/release/check-changelog.sh LAST-RELEASE-TAG...main and add missing PRs to CHANGELOG
  • Ensure CHANGELOG entries are sorted by type
  • Add a new section for the new release so that ## main / unreleased is blank and at the top. The new section should say ## x.y.0-rc.0.
• Run ./tools/release/notify-changelog-cut.sh
• Run make mixin-screenshots
  • Before opening the PR, review all updated screenshots and ensure no sensitive data is disclosed
• Create new release branch
  • Create the branch

    git checkout r<xxx> # xxx is the latest weekly release
    git checkout -b release-<version>
    git push -u origin release-<version>

  • Remove "main / unreleased" section from the CHANGELOG
  • Adjust the settings in the renovate.json configuration on the main branch to ensure that dependency updates maintain the latest two minor versions. For instance, if the current release version is 3.0, this means keeping versions 3.0 and the latest minor version from major version 2, such as 2.10.
• Publish the Mimir release candidate
  • Update VERSION in the release branch and update CHANGELOG with version and release date.
    • Keep in mind this is a release candidate, so the version string in VERSION and CHANGELOG must end in -rc.#, where # is the release candidate number, starting at 0.
  • Tag the release

    git checkout release-<version>
    ./tools/release/tag-release.sh

  • Wait until the CI pipeline succeeds
  • Create a pre-release on GitHub

    git checkout release-<version>
    ./tools/release/create-draft-release.sh

  • Merge the release branch release- into main

    ./tools/release/create-pr-to-merge-release-branch-to-main.sh

  • Publish the Github pre-release draft after getting review from at least one maintainer
  • Announce the release candidate on social media such as on Mimir community slack using your own Twitter, Mastodon or LinkedIn account
• Vendor the release commit of Mimir into Grafana Enterprise Metrics (GEM)
  • This is addressed by Grafana Labs

Publish the stable release

• Publish the Mimir stable release
  • Write release notes
    • Ensure the any change to release notes in main has been cherry picked to the release branch
  • Update version in release- branch
    • VERSION
    • CHANGELOG
    • operations/mimir/images.libsonnet (_images.mimir and _images.query_tee fields)
    • operations/mimir-rules-action/Dockerfile (grafana/mimirtool image tag)
  • Tag the release

    git checkout release-<version>
    ./tools/release/tag-release.sh

  • Wait until the CI pipeline succeeds
  • Create a release on GitHub

    git checkout release-<version>
    ./tools/release/create-draft-release.sh

  • Merge the release branch release- into main

    ./tools/release/create-pr-to-merge-release-branch-to-main.sh

  • Announce the release on socials
  • Open a PR to add the new version to the backward compatibility integration test (integration/backward_compatibility_test.go)
  • Publish dashboards to grafana.com