Release 3.0

[dimitarvdimitrov]

Publish rc.0

• Add 3.0.0 release with Dimitar as shepherd #13062
• Begin drafting the release notes [release-3.0] Add release notes for 3.0 #13093
  • 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 Update CHANGELOG.md for release-3.0 #13065 [release-3.0] Update CHANGELOG.md for release-3.0 #13070
  • 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 Update dashboard screenshots for release 3.0 #13069 [release-3.0] Update dashboard screenshots for release 3.0 #13071
  • 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 [release-3.0] Update CHANGELOG.md for release-3.0 #13070
  • 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. Update renovate.json5 with 3.0 release #13072
    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. [release-3.0] Update VERSION for rc.0 #13073
    • 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-71979b71c55592279479

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

  • Merge the release branch release- into main Merge release-3.0 to main #13076

    ./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 https://github.com/grafana/mimir/releases/tag/mimir-3.0.0-rc.0
  • 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
  • Skipped because there is no GEM 3.0
• Publish a mimir-distributed Helm chart release candidate. Follow the instructions in Release process for a release candidate helm: release 6.0.0 #13075
• 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
    • compactor, store-gateway: always upload sparse headers #13089
    • distributor: Remove experimental feature Metric Relabeling per Tenant #13143
    • Ingester: promote read path cpu & memory utilization limit flags #13167
    • Promote out of order flags #13132
    • Querier: Promote -querier.max-estimated-fetched-chunks-per-query-multiplier to stable #13120
    • Promote postings for matchers cache to stable #13101
    • alertmanager: Deprecate UTF-8 strict mode flag and default to true #13109
    • API: Promote /api/v1/cardinality/active_series to stable #13111
    • querier: Promote -querier.active-series-results-max-size-bytes to stable #13110
    • compactor: remove experimental flag for no-blocks cleanup #13108
    • query-frontend: Promote query blocking feature to stable #13107
    • feat: remove experimental heartbeat/timeout disabling #13104
    • feat: remove experimental heartbeat/timeout disabling dskit#759
    • ruler: promote align_evaluation_time_on_interval to stable #13103
    • Remove eager_loading_startup_enabled config because we want to permanently enabled it when lazyLoading is enabled #13126
    • Promote rate limit logger configurations #13128
    • compactor, store-gateway: always upload sparse headers #13089
    • block upload: update documentation to remove experimental warning #13116
  • Open a PR into main branch with any deprecated feature or configuration option removed in the next release
    • docs: adjust about-versioning.md #13094
• Publish the Mimir release candidate (rc.1)
  • Update VERSION in the release branch and update CHANGELOG with version and release date. [release-3.0] Update version to 3.0.0-rc.1 #13193
    • 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/mimir-3.0.0-rc.1

    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
• Vendor the release commit of Mimir into Grafana Enterprise Metrics (GEM)
  • This is addressed by Grafana Labs
  • Skipped because there is no GEM 3.0
• Publish a mimir-distributed Helm chart release candidate. Follow the instructions in Release process for a release candidate

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
  • 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
  • After publishing a GEM release publish the mimir-distributed Helm chart. Follow the instructions in Release process for a final release