|
| 1 | +# 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. See also [prioritization](./prioritization.md) for how priority of issues and regressions |
| 6 | +are determined. |
| 7 | + |
| 8 | +In case a backport is applied to the stable channel, the Rust project will release a patch release |
| 9 | +(for example a 1.87.1 point release could follow the initial stable release 1.87.0). |
| 10 | + |
| 11 | +## Nominating for backport review |
| 12 | + |
| 13 | +You can propose a change be backported by applying labels to the GitHub pull request. Add |
| 14 | +`beta-nominated` if the patch should be backported to the **beta** channel, and also |
| 15 | +`stable-nominated` if it needs backported to the **stable** channel. Make sure the pull request has |
| 16 | +a [`T-compiler`] label as well. |
| 17 | + |
| 18 | +In any case, you should **add a comment when you nominate the pull request for backport** providing |
| 19 | +context for the compiler team backport reviewers about why it should be backported. |
| 20 | + |
| 21 | +**Backport nominations are not guaranteed be accepted**. Please refer to the [*Should the backport |
| 22 | +be approved*](#should-the-backport-be-approved) section below for the criteria on which backport |
| 23 | +nominations may be accepted or rejected. |
| 24 | + |
| 25 | +Beta regressions that slid to the stable channel will need a stable backport nomination (and a |
| 26 | +subsequent patch release, if approved). |
| 27 | + |
| 28 | +The compiler team tries to make sure that critical issues (labeled with `P-critical`) do not |
| 29 | +progress to the stable release. |
| 30 | + |
| 31 | +## Reviewing compiler backport nominations |
| 32 | + |
| 33 | +When one of [`beta-nominated`] or [`stable-nominated`] label is applied, a new thread is |
| 34 | +automatically opened on Zulip in the [#t-compiler/backports] channel. Compiler team members can use |
| 35 | +these Zulip threads to cast their vote asynchronously in favor of or raise concerns about |
| 36 | +backporting. If you are a compiler team member and want to be notified of these threads, you should |
| 37 | +subscribe that zulip channel. |
| 38 | + |
| 39 | +During the weekly triage meeting (happening on [#t-compiler/meetings], see [here](./meetings.md)), |
| 40 | +the compiler team will finalize the decision and apply the relevant `{beta,stable}-accepted` label. |
| 41 | + |
| 42 | +### Should the backport be approved? |
| 43 | + |
| 44 | +For compiler backport reviewers, here are some **non-exhaustive** considerations that they might |
| 45 | +consider in making a backport decision: |
| 46 | + |
| 47 | +- The nominated change is not merged in time for the stable or beta release channel (e.g. due to |
| 48 | + implementation issues). |
| 49 | +- Has the backport enough time to be tested? |
| 50 | + - (For beta backport nominations) The nominated change would be applied too close to the next |
| 51 | + stable compiler release. Merging a backport at this time will mean very limited (if any) time |
| 52 | + for testing. |
| 53 | + - A stable point release will be *immediately* available to all users without any time to bake! |
| 54 | +- How complex or risky is the nominated compiler change? Is the risk of the backport introducing new |
| 55 | + regressions potentially worse than the regression or issue it addresses? |
| 56 | +- How severe is the regression/issue being fixed? |
| 57 | + - For example stable regressions are not all equal: some are not very severe or are already on |
| 58 | + stable channel since multiple releases. |
| 59 | + |
| 60 | +By default, approved stable backports will cause a new point release to be issued by the [release |
| 61 | +team](../release/backporting.md#stable-backporting-in-rust-langrust). |
| 62 | + |
| 63 | +However, the compiler team may approve a stable backport, but additionally indicate to the [release |
| 64 | +team](../release/backporting.md) that the nomination does not justify a stable point release *on its |
| 65 | +own*. In this case, the release team will consider other approved stable backport candidates and how |
| 66 | +serious those are in conjunction with this candidate, to finalize a decision on whether to execute a |
| 67 | +stable point release. |
| 68 | + |
| 69 | +## How are approved backports handled? |
| 70 | + |
| 71 | +The [release team](../release/README.md) (`T-release`) will handle the backport at the end of the |
| 72 | +current development cycle (see [release backporting](../release/backporting.md)). If a beta backport |
| 73 | +nomination is approved too late, the release team may be unable to backport the change. |
| 74 | + |
| 75 | +Most of the time, accepted backports target the `master` branch. In rare circumstances, a beta |
| 76 | +backport may need to *directly* target the `beta` branch. In this case, coordinate with the release |
| 77 | +team before merging, by opening a new thread on the Zulip [#t-release |
| 78 | +channel](https://rust-lang.zulipchat.com/#narrow/channel/241545-t-release)). |
| 79 | + |
| 80 | +For complicated backports, the release team may ask the patch author for assistance. |
| 81 | + |
| 82 | + |
| 83 | +[`beta-nominated`]: https://github.com/rust-lang/rust/labels/beta-nominated |
| 84 | +[`beta-accepted`]: https://github.com/rust-lang/rust/labels/beta-accepted |
| 85 | +[`stable-nominated`]: https://github.com/rust-lang/rust/labels/stable-nominated |
| 86 | +[`stable-accepted`]: https://github.com/rust-lang/rust/labels/stable-accepted |
| 87 | +[#t-compiler/backports]: |
| 88 | + https://rust-lang.zulipchat.com/#narrow/channel/474880-t-compiler.2Fbackports |
| 89 | +[#t-compiler/meetings]: https://rust-lang.zulipchat.com/#narrow/channel/238009-t-compiler.2Fmeetings |
| 90 | +[`T-compiler`]: https://github.com/rust-lang/rust/labels/T-compiler |
0 commit comments