Release Mimir 3.1.0

[armandgrillet]

This issue is tracking the progress of the release 3.1.0. The release candidate is not scheduled just yet.

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. Cut changelog for Mimir 2.9 #5167
• Run ./tools/release/notify-changelog-cut.sh
• Run make mixin-screenshots Add dashboard screenshots for Mimir 2.9 #5168
  • 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
• 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

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

[alexraileanu]

hello, i have one tiny question regarding this release.

with this release, do you plan on updating the helm charts as well? there's a hardcoded environment value in the kafka statefulset in version 6.0.5 which we would really benefit from being able to change!

[wilfriedroset]

@armandgrillet do you have room for one more contribution in the 3.1 release?
We have been working hard on a feature, #13665 and we can allocate more time on it if needed, but for that we would need your inputs?