@ -115,25 +115,12 @@ In case the pull request introduces a breaking change you should document this.
<Breakingchangedescription>
<Breakingchangedescription>
```
```
### Should the pull request be backported?
### Backporting
Backporting is the process of copying the pull request into the version branch of one or multiple previous releases.
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.
This is a rare exception, 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 your pull request fixes a critical bug and needs to be backported, add it to the "Critical Bug Release" form so the team can approve the backport and know that a release needs to be made. Specify the correct `backport vx.x` labels for the releases the fix needs to be backported to. Once approved, the backporting process will continue from there.
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 fixes a critical bug and needs to go into one or several existing release branches it should be backported.
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.