Sometimes compiler fixes need to be backported to the stable and/or beta channel to fix a significant regression or to revert unintentional changes that weren't noticed when originally merged.
In case a backport is applied to the stable channel, the Rust project will release a patch release (for example a 1.87.1 point release could follow the initial stable release 1.87.0).
You can suggest evaluating a change to be backported by applying suitable labels to a GitHub pull request:
beta-nominated
stable-nominated
or both, if the change should be considered to be backported to both release channels. Make sure the pull
request has a T-compiler
label as well.
In any case, you should add a comment when you nominate the pull request for backport providing context for the compiler team backport reviewers about why it should be backported.
Backport nominations are not guaranteed be accepted.
Backports could be declined if compiler team determines that:
Beta regressions that slid to the stable channel will need a stable backport nomination (and a subsequent patch release, if approved).
The compiler team tries to make sure that critical issues (labeled with P-critical
) do not
progress to the stable release.
When one of beta-nominated
or stable-nominated
label is applied, a new thread is
automatically opened on Zulip in the #t-compiler/backports channel. Compiler team members can use
these Zulip threads to cast their vote asynchronously in favor of or raise concerns about backporting. If you are a
compiler team member and want to be notified of these threads, you should subscribe that zulip channel.
During the weekly triage meeting (happening on #t-compiler/meetings, see here),
the compiler team will finalize the decision and apply the relevant {beta,stable}-accepted
label.
For compiler backport reviewers, here are some non-exhaustive considerations that they might consider in making a backport decision:
At the end of the day, it's a risk vs benefit tradeoff decision.
The release team (T-release
) will handle the backport at the end of
the current development cycle (see release backporting). If a
beta backport nomination is approved too late, the release team may be unable to backport the change.
Most of the time, accepted backports target the master
branch. In rare circumstances, a beta
backport may need to directly target the beta
branch. In this case, coordinate with the release
team before merging, by opening a new thread on the Zulip #t-release
channel).