Release 2.12

[duricanikolic]

This issue is tracking the progress of the release 2.12.0. The release candidate is scheduled for the week of March 11th 2024.

Publish the release candidate

• [x] 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
• [x] 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
  • [x] Eventually open a PR for every experimental feature we want to promote to stable
  • [x] Eventually open a PR to remove any deprecated feature or configuration option that should be removed in this release
• [x] Update CHANGELOG.md
  • [x] Run ./tools/release/check-changelog.sh LAST-RELEASE-TAG...main and add missing PRs to CHANGELOG
  • [x] Ensure CHANGELOG entries are sorted by type
  • [x] 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.
• [x] Run ./tools/release/notify-changelog-cut.sh
• [x] Run make mixin-screenshots
  • Before opening the PR, review all updated screenshots and ensure no sensitive data is disclosed
• [x] Create new release branch
  • [x] Create the branch

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

  • [x] Remove "main / unreleased" section from the CHANGELOG
  • [x] If a new minor or major version is being released, adjust the settings in the renovate.json configuration on the main branch by adding the new version. This way we ensure that dependency updates maintain the new version, as well as the latest two minor versions. For instance, if versions 3.0 and 2.10 are configured in renovate.json, and version 3.1 is being released, during the release process renovate.json should keep updated the following branches: main, release-3.1, release-3.0 and release-2.10.
• [ ] Publish the Mimir release candidate
  • [x] 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.
  • [x] Tag the release

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

    • [x] mimir-2.12.0-rc.0
    • [x] mimir-2.12.0-rc.1
  • [x] Wait until the CI pipeline succeeds
  • [x] Create a pre-release on GitHub

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

  • [x] Merge the release branch release- into main

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

    • [x] Mimir 2.12.0-rc.0: https://github.com/grafana/mimir/pull/7610
    • [x] Mimir 2.12.0-rc.4: https://github.com/grafana/mimir/pull/7672
  • [x] Publish the Github pre-release draft after getting review from at least one maintainer
    • [x] Pre-release 2.12.0-rc.0
    • [x] Pre-release 2.12.0-rc.1
  • [ ] 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)
  • [x] Mimir 2.12.0-rc.1: https://github.com/grafana/backend-enterprise/pull/6041

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
    

  • [ ] If during the release process settings in the renovate.json have been modified in such a way that dependency updates maintain more than the latest two minor versions, modify it again to ensure that only the latest two minor versions get updated. For instance, if versions 3.1, 3.0 and 2.10 are configured in renovate.json, renovate.json should keep updated the following branches: main, release-3.1 and release-3.0.
  • [ ] 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