|
| 1 | +# Compiler change backports |
| 2 | + |
| 3 | +Sometimes compiler fixes need to be backported to the stable and/or beta channel to fix a |
| 4 | +significant regression or to revert unintentional changes that weren't noticed when originally |
| 5 | +merged. |
| 6 | + |
| 7 | +In case a backport is applied to the stable channel, the Rust project will release a patch release |
| 8 | +(for example a 1.87.1 point release could follow the initial stable release 1.87.0). |
| 9 | + |
| 10 | +## Nominating for compiler backport review |
| 11 | + |
| 12 | +You can suggest evaluating a change to be backported by applying suitable labels to a GitHub pull |
| 13 | +request: |
| 14 | + |
| 15 | +- Nominate for **beta** channel backport: [`beta-nominated`] |
| 16 | +- Nominate for **stable** channel backport: [`stable-nominated`] |
| 17 | + |
| 18 | +or both, if the change should be considered to be backported to both release channels. Make sure the |
| 19 | +pull request has a [`T-compiler`] label as well. |
| 20 | + |
| 21 | +In any case, you should **add a comment when you nominate the pull request for backport** providing |
| 22 | +context for the compiler team backport reviewers about why it should be backported. |
| 23 | + |
| 24 | +**Backport nominations are not guaranteed be accepted**. |
| 25 | + |
| 26 | +Backports could be declined if compiler team determines that: |
| 27 | + |
| 28 | +- The **benefit** of backporting **does not sufficiently outweigh the risk of introducing *new* |
| 29 | + regressions** to the beta/stable channels. |
| 30 | +- The nominated change is **too complex** (which typically correlates with being too risky) to |
| 31 | + backport. |
| 32 | +- The nominated change is not merged in time for the stable or beta release channel (e.g. due to |
| 33 | + implementation issues). |
| 34 | +- (For beta backport nominations) The nominated change would be applied too close to the next stable |
| 35 | + compiler release. Merging a backport at this time will mean very limited (if any) time for |
| 36 | + testing. |
| 37 | +- (For stable backport nominations) The nominated change does not sufficiently justify a patch |
| 38 | + release on its own. Patch compiler releases usually happen when more backports pile up in the same |
| 39 | + timespan. There is a *significantly higher bar* for stable backports and thus point releases, |
| 40 | + because that *immediately* affects all stable channel users who update to the new point release. |
| 41 | + In addition, not all stable regressions are equal: some are not very severe or are already there |
| 42 | + since multiple releases. |
| 43 | + |
| 44 | +Beta regressions that slid to the stable channel will need a stable backport nomination (and a |
| 45 | +subsequent patch release, if approved). |
| 46 | + |
| 47 | +The compiler team tries to make sure that critical issues (labeled with `P-critical`) do not |
| 48 | +progress to the stable release. |
| 49 | + |
| 50 | +## Reviewing compiler backport nominations |
| 51 | + |
| 52 | +When one of [`beta-nominated`] or [`stable-nominated`] label is applied, a new thread is |
| 53 | +automatically opened on Zulip in the [#t-compiler/backports] channel. Compiler team members can use |
| 54 | +these Zulip threads to cast their vote asynchronously in favor of or raise concerns about |
| 55 | +backporting. If you are a compiler team member and want to be notified of these threads, you should |
| 56 | +subscribe that zulip channel. |
| 57 | + |
| 58 | +During the weekly triage meeting (happening on [#t-compiler/meetings], see [here](./meetings.md)), |
| 59 | +the compiler team will finalize the decision and apply the relevant `{beta,stable}-accepted` label. |
| 60 | + |
| 61 | +### Should the backport of X be appoved? |
| 62 | + |
| 63 | +For compiler backport reviewers, here are some **non-exhaustive** considerations that they might |
| 64 | +consider in making a backport decision: |
| 65 | + |
| 66 | +- Has the backport enough time to be tested? |
| 67 | + - A stable point release will be *immediately* available to all users without any time to bake! |
| 68 | +- How complex or risky is the nominated compiler change? Is the risk of the backport introducing new |
| 69 | + regressions potentially worse than the regression or issue it addresses? |
| 70 | +- How severe is the regression/issue being fixed? |
| 71 | + - For example stable regressions are not all equal: some are not very severe or are already on |
| 72 | + stable channel since multiple releases. |
| 73 | + |
| 74 | +At the end of the day, it's a risk vs benefit tradeoff decision. |
| 75 | + |
| 76 | +## How are approved backports handled? |
| 77 | + |
| 78 | +The [release team](../release/README.md) (`T-release`) will handle the backport at the end of the |
| 79 | +current development cycle (see [release backporting](../release/backporting.md)). If a beta backport |
| 80 | +nomination is approved too late, the release team may be unable to backport the change. |
| 81 | + |
| 82 | +Most of the time, accepted backports target the `master` branch. In rare circumstances, a beta |
| 83 | +backport may need to *directly* target the `beta` branch. In this case, coordinate with the release |
| 84 | +team before merging, by opening a new thread on the Zulip [#t-release |
| 85 | +channel](https://rust-lang.zulipchat.com/#narrow/channel/241545-t-release)). |
| 86 | + |
| 87 | + |
| 88 | +[`beta-nominated`]: https://github.com/rust-lang/rust/labels/beta-nominated |
| 89 | +[`beta-accepted`]: https://github.com/rust-lang/rust/labels/beta-accepted |
| 90 | +[`stable-nominated`]: https://github.com/rust-lang/rust/labels/stable-nominated |
| 91 | +[`stable-accepted`]: https://github.com/rust-lang/rust/labels/stable-accepted |
| 92 | +[#t-compiler/backports]: |
| 93 | + https://rust-lang.zulipchat.com/#narrow/channel/474880-t-compiler.2Fbackports |
| 94 | +[#t-compiler/meetings]: https://rust-lang.zulipchat.com/#narrow/channel/238009-t-compiler.2Fmeetings |
| 95 | +[`T-compiler`]: https://github.com/rust-lang/rust/labels/T-compiler |
0 commit comments