From f1d704b48b90483a5f120a84d26a18e8188a6968 Mon Sep 17 00:00:00 2001 From: Horst Gutmann Date: Wed, 30 Aug 2023 08:14:15 +0200 Subject: [PATCH] Docs: Update contrib documentation around backports (#73558) --- WORKFLOW.md | 5 ++--- contribute/merge-pull-request.md | 30 ++++++++++++------------------ 2 files changed, 14 insertions(+), 21 deletions(-) diff --git a/WORKFLOW.md b/WORKFLOW.md index 633a996cf6a..fca782e178d 100644 --- a/WORKFLOW.md +++ b/WORKFLOW.md @@ -43,9 +43,8 @@ Once a PR is approved as per above, any team member MAY merge the PR. ## Backporting a PR -PRs intended for inclusion in the next PATCH release they must be backported to the release branch. The bot can do this automatically. [Read more on backport PRs](https://github.com/grafana/grafana/blob/main/.github/bot.md). Both the source PR and the backport PR should be assigned to the patch release milestone, unless you are backporting to many releases then it can differ. - -Backport PRs are also needed during the beta period to get fixes into the stable release. +Critical bug fixes needed for a previous minor release should be backported to the respective release branches after coordinating with the delivery team. +Please see the [contibution guide](./contribute/merge-pull-request.md#should-the-pull-request-be-backported) for further details. # Release workflow diff --git a/contribute/merge-pull-request.md b/contribute/merge-pull-request.md index e5b721490a7..a2efc8eec9e 100644 --- a/contribute/merge-pull-request.md +++ b/contribute/merge-pull-request.md @@ -49,7 +49,7 @@ Instead, when it is merged & closed then a bot will look for the most appropriat That milestone should always reflect the branch that the pull request is merged into. For every major and minor release there is a milestone ending with `.x` (e.g. `10.0.x` for the 10.0.x releases). Pull requests targetting `main` should use the `.x` milestone of the next minor (or major) version (you can find that version number inside the `package.json` file). -Backport pull requestss should use the version of the target branch (e.g. `9.4.x` for the `v9.4.x` branch). +Backport pull requests should use the version of the target branch (e.g. `9.4.x` for the `v9.4.x` branch). ### Include in changelog and release notes? @@ -117,30 +117,23 @@ In case the pull request introduces a breaking change you should document this. ### Should the pull request be backported? -An active decision of backporting needs to be taken for every pull request. There's a pull request check named **Backport Check** that will enforce this. By adding/removing labels on the pull request the check will be re-evaluated. +Backporting is the process of copying the pull request into the version branch of one or multiple previous releases. +This should only be done for _critical bug fixes_ and involves the intervention of a Grafana Labs employee. +To make this decision explicit, there is a **Backport Check** that is re-evaluated automatically by adding/removing labels on the pull request. #### No backport If you don't want to backport you need to add a label named **no-backport** to the pull request. +This should be the default! + #### Backport -If your pull request has changes that need to go into one or several existing release branches you need to backport the changes. Please refer to [Backport PR](/.github/bot.md#backport-pr) for detailed instructions. +If your pull request fixes a critical bug and needs to go into one or several existing release branches it should be backported. -The general rule of thumb regarding what changes goes into what release is: - -- bug fixes should be released in patch releases, e.g. v8.1.3, if the bug was introduced in the same major/minor or lower patch version. -- new features should go into the next major/minor version, e.g. v8.0.0, v8.2.0. - -Some examples when backport is required: - -- The change needs to be released in the next upcoming patch release, e.g. v8.1.3, so you have to backport it, e.g. into the v8.1.x release branch. -- You have a change to be released in the next major/minor release, e.g. v8.0.0, and there's already a release branch, e.g. v8.0.x, you have to backport it, e.g. into the v8.0.x release branch. -- The change includes documentation changes that needs to be updated for one or multiple older versions, then you have to backport it to each release branch. - -Some examples when backport is not required: - -- The change is supposed to be released in the next major/minor release, e.g. v8.0.0, but the release branch, e.g. v8.0.x, has not yet been created. +For a pull request to be backported, please add it to "Critical Bug Release" form so that the delivery team is aware that a release for a previous version needs to be made. +Once approved, the backporting process will continue from there. +In the meantime, set the `no-backport` label. #### Required labels @@ -148,7 +141,8 @@ To ensure that we don't backport pull requests that don't need to be backported, - `type/bug` label: Pull requests which address bugs, - `product-approved` label: Urgent fixes which need product approval, in order to get merged, -- `type/docs` label: Docs changes`. +- `type/docs` label: Docs changes. +- `type/ci` label: Changes to the CI automation. > **Note:** You can still backport a pull request after it's been merged.