RELEASE.md

Release Process

The Metrics Server is released on an as-needed basis. The process is as follows:

1. An issue is proposing a new release with a changelog since the last release https://github.com/kubernetes-sigs/metrics-server/compare
2. At least one OWNER must LGTM this release
3. A PR that bumps version hardcoded in code is created and merged
4. An OWNER creates a draft GitHub release
5. An OWNER creates an issue to release the corresponding Helm chart via the chart release process (below)
6. An OWNER creates a release tag using GIT_TAG=$VERSION make release-tag and waits for prow.k8s.io to build and push new images to gcr.io/k8s-staging-metrics-server
7. A PR in kubernetes/k8s.io is created to release images to k8s.gcr.io
8. An OWNER publishes the GitHub release. Once published, release manifests will be automatically added to the release by CI.
9. An announcement email is sent to kubernetes-sig-instrumentation@googlegroups.com with the subject [ANNOUNCE] metrics-server $VERSION is released
10. The release issue is closed

Chart Release Process

A new chart should be released whenever a new version of Metrics Server is released, but releases can also be done on an as-needed basis. Most chart releases for the latest Metrics Server version can take place on the master branch. However, if a release is a backport or the chart on master is no longer compatible, the PR should target the release branch.

The chart release process is as follows:

1. An issue is proposing a new chart release
2. The issue is used to document the release process
3. A PR is opened to update Chart.yaml with the appVersion, version
4. The PR triggers the chart linting and testing GitHub action to validate the chart
5. The PR is merged and a GitHub action releases the chart

If the release has happened on a release branch the issue will need manually closing.