Release Mimir 3.2.0

[armandgrillet]

This issue is tracking the progress of the release 3.2.0. The release candidate is scheduled for end of July/August.

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
• 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 CHANGELOG.md
• 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
  • If a new minor or major version is being released, adjust the settings in the renovate.json5 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.json5 should keep updated the following branches: main, release-3.1, release-3.0 and release-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
    • https://github.com/grafana/mimir/releases/tag/untagged-ae612393802a262dd31e

    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

    This prepares a PR into main branch. On approval, use the merge-approved-pr-branch-to-main.sh script, following the instruction on how to merge the PR with "Merge commit" (i.e. we DO NOT "Squash and merge" this one).
  • 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
• Publish a mimir-distributed Helm chart release candidate. Follow the instructions in Release process for a release candidate
• Promote experimental features to stable and remove deprecated features for the next release:
  • Open a PR into main branch for every experimental feature we want to promote to stable
  • Open a PR into main branch with any deprecated feature or configuration option removed in the next release

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
    • NOTE: The release notes should be included at docs/sources/mimir/release-notes on the branch before tagging 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

    This prepares a PR into main branch. On approval, use the merge-approved-pr-branch-to-main.sh script, following the instruction on how to merge the PR with "Merge commit" (i.e. we DO NOT "Squash and merge" this one).
  • If during the release process settings in the renovate.json5 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.json5, renovate.json5 should keep updated the following branches:
    main, release-3.1 and release-3.0.
  • Announce the release on socials
    • https://grafana.slack.com/archives/C039863E8P7/p1780478117470049
  • Open a PR to add the new version to the backward compatibility integration test (integration/backward_compatibility.go)
    • Keep the last 3 minor releases
  • Ensure the workflow to sync linux packages (RPM, deb) runs successfully within the next N hours or trigger it manually
  • Open a PR to update the mixin in "Self-hosted Grafana Mimir" integration
    • This is addressed by Grafana Labs
  • Publish dashboards to grafana.com
    • This is addressed by Grafana Labs
  • Publish the mimir-distributed Helm chart. Follow the instructions in Release process for a final release