IntenseWebs/grafana
3
0
Fork 0
mirror of https://github.com/grafana/grafana.git synced 2025-02-25 18:55:37 -06:00
Code Issues Packages Projects Releases Wiki Activity

Docs: Update contrib documentation around backports (#73558)

Browse Source
This commit is contained in:
Horst Gutmann 2023-08-30 08:14:15 +02:00 committed by GitHub
parent a39d1e278e
commit f1d704b48b
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 14 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
WORKFLOW.md
View File

@ -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

30
contribute/merge-pull-request.md
View File

@ -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.