diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md index 9ee1c73c4e..b280e24d90 100644 --- a/.github/PULL_REQUEST_TEMPLATE.md +++ b/.github/PULL_REQUEST_TEMPLATE.md @@ -5,9 +5,14 @@ 4. If the PR is unfinished, see how to mark it: https://git.k8s.io/community/contributors/guide/pull-requests.md#marking-unfinished-pull-requests --> -**What this PR does / why we need it**: +**What this PR does / why we need it**: -**How does this change affect the cardinality of KSM**: *(increases, decreases or does not change cardinality)* +**How does this change affect the cardinality of KSM**: -**Which issue(s) this PR fixes** *(optional, in `fixes #(, fixes #, ...)` format, will close the issue(s) when PR gets merged)*: -Fixes # +**Which issue(s) this PR fixes**: + +**Choose one below, based on the nature of this PR:** + - [ ] BUGFIX + - [ ] CHANGE + - [ ] ENHANCEMENT + - [ ] FEATURE diff --git a/RELEASE.md b/RELEASE.md index 072da51edf..0aef4694ce 100644 --- a/RELEASE.md +++ b/RELEASE.md @@ -2,41 +2,64 @@ ## Branch management and versioning strategy -We use [Semantic Versioning](http://semver.org/). +### Semantic versioning -We maintain a separate branch for each minor release, named `release-.`, e.g. `release-1.1`, `release-2.0`. +We use [Semantic Versioning](http://semver.org/), and thus, maintain a separate branch for each minor release, named +`release-.`, e.g. `release-1.1`, `release-2.0`. -The usual flow is to merge new features and changes into the main branch and to merge bug fixes into the latest release branch. Bug fixes are then merged into main from the latest release branch. The main branch should always contain all commits from the latest release branch. +### Workflow -If a bug fix got accidentally merged into main, cherry-pick commits have to be created in the latest release branch, which then have to be merged back into main. Try to avoid that situation. +- The usual flow is to merge new features and changes into the main branch and to merge (the later) bug fixes into the +latest release branch. +- Bug fixes are then merged into main from the latest release branch. +- The main branch should always contain **all** commits from the latest release branch. +- If a bug fix got accidentally merged into main, cherry-pick commits have to be created in the latest release branch, +which then have to be merged back into main. Try to avoid that situation. +- Maintaining the release branches for older minor releases happens on a **best effort** basis. -Maintaining the release branches for older minor releases happens on a best effort basis. +## Preparing the release -## Prepare your release +Note: For a stable release, first a release candidate (e.g. `v1.2.0-rc.0`) should be cut. If, after a period of +**7 days**, no bugs or issues were reported after publishing the release candidate, a stable release (e.g. `v1.2.0`) +can be cut. -* Bump the version in the `VERSION` file in the root of the repository. -* Run `make examples`, which will re-generate all example manifests to use the new version. -* Make a PR to update: - * [Compatibility matrix](README.md#compatibility-matrix) - * Changelog entry - * Only include user relevant changes +### Workflow + +* Bump the version in [`VERSION.md`](VERSION.md). +* Run `make examples`, which will re-generate all example manifests to use the newer version. +* Cut the new release branch, e.g. `release-1.2`, or merge/cherry-pick changes onto the minor release branch you intend +to tag the release on. +* Include the following changes in the release PR (cut from `main`). + * Update the [compatibility matrix](README.md#compatibility-matrix). + * Add changelog entries. * Entries in the [`CHANGELOG.md`](CHANGELOG.md) are meant to be in this order: ``` + [BUGFIX] [CHANGE] - [FEATURE] [ENHANCEMENT] - [BUGFIX] + [FEATURE] ``` - * All lines should be full sentences - * kube-state-metrics image tag used in Kubernetes deployment yaml config. -* Cut the new release branch, e.g. `release-1.2`, or merge/cherry-pick changes onto the minor release branch you intend to tag the release on -* Cut the new release tag, e.g. `v1.2.0-rc.0` -* Create a new **pre-release** on github -* New images are automatically built and pushed to `gcr.io/k8s-staging-kube-state-metrics/kube-state-metrics` -* Promote image by sending a PR to [kubernetes/k8s.io](https://github.com/kubernetes/k8s.io) repository. Follow the [example PR](https://github.com/kubernetes/k8s.io/pull/3798). Use [kpromo pr](https://github.com/kubernetes-sigs/promo-tools/blob/main/docs/promotion-pull-requests.md) to update the manifest files in this repository, e.g. `kpromo pr --fork=$YOURNAME -i --project=kube-state-metrics -t=v2.5.0` -* Create a PR to merge the changes of this release back into the main branch. -* Once the PR to promote the image is merged, mark the pre-release as a regular release. - -## Stable release - -First a release candidate (e.g. `v1.2.0-rc.0`) should be cut. If after a period of 7 days no bugs or issues were reported after publishing the release candidate, a stable release (e.g. `v1.2.0`) can be cut. + * To generate changelog, follow the process below: + * Fetch all commits since last release, for instance, when preparing for `v2.9.0`, do + `git log --oneline --decorate upstream/release-2.8..upstream/main`. + * Remove all merge commits, `fixup!`s (if any), and any commits that might have crept in from a PR, other + than it's original commit, unless wanted otherwise. + * Remove all non-user-facing changes. + * Label the remaining commits under the aforementioned categories, and futher condense commit groups + under their associated PRs, wherever possible. + * Format the message in the manner: `[] `. + * All lines should be full sentences. +* Cut the new release-candidate tag, e.g. `v1.2.0-rc.0`. +* Create a new **pre-release**. +* Create a PR to merge the changes of this release back into the `main` branch. +* Once the PR to promote the image is merged, mark the pre-release as a regular release. This must be done after the + **7-day** period is over. + +### Post-release chores + +* Promote the latest release image, refer [k8s.io/#4750](https://github.com/kubernetes/k8s.io/pull/3798) for more + details. Also see [promotion-pull-requests.md#promoting-images](https://github.com/kubernetes-sigs/promo-tools/blob/main/docs/promotion-pull-requests.md#promoting-images). + * For instance, `kpromo pr --fork mrueg -i --project kube-state-metrics --reviewers="@fpetkovski,@dgrisonnet,@rexagod" -t=v2.8.2 --image="" --digests=""`. + * Open a PR promoting the image (based on aforementioned links). + * New images will be automatically built and pushed to `gcr.io/k8s-staging-kube-state-metrics/kube-state-metrics`. +