Skip to content

Commit bdee510

Browse files
committed
Add Cargo backport instructions
1 parent 373eaef commit bdee510

File tree

1 file changed

+41
-7
lines changed

1 file changed

+41
-7
lines changed

beta-backporting.md

Lines changed: 41 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,15 @@
1+
---
2+
layout: default
3+
title: Beta Backporting · The Rust Programming Language
4+
---
5+
6+
# Beta Backporting
7+
18
There's a steady trickle of patches that need to be ported to the beta
29
branch. Only a few people are even aware of the process, but this is
3-
actually something anybody can do. Here's how it works:
10+
actually something anybody can do.
11+
12+
## Backporting in `rust-lang/rust`
413

514
When somebody identifies a PR that should be backported to beta they
615
tag it
@@ -19,15 +28,40 @@ ready for a backport is those tagged [both `beta-nominated` and
1928

2029
So now somebody needs to go through those PR's and cherry-pick their
2130
commits to the beta branch. Those cherry-picks are then submitted as a
22-
PR _against the beta branch_, with a title started with `beta` (so
31+
PR _against the beta branch_, with a title started with `[beta]` (so
2332
reviewers can see its specialness). The OP of that PR should contain
2433
links to all the PRs being backported. [Here's an
2534
example](https://github.com/rust-lang/rust/pull/36634). Anybody can
2635
make these PRs!
2736

2837
After that a reviewer needs to verify that the backport looks correct,
29-
that it's submitted to the beta branch, and then hit the merge
30-
button. Finally, they need to follow the links to the original PRs and
31-
_remove the `beta-nominated` tag_ (people forget to do this a
32-
lot). This last step indicates that the backport has been completed,
33-
so the `beta-nominated` and `beta-accepted` tags have three states.
38+
that it's submitted to the beta branch, and then approve via `@bors: r+`.
39+
Finally, they need to follow the links to the original PRs and _remove the
40+
`beta-nominated` tag_ (people forget to do this a lot). This last step indicates
41+
that the backport has been completed, so the `beta-nominated` and
42+
`beta-accepted` tags have three states.
43+
44+
## Backporting in `rust-lang/cargo`
45+
46+
The procedure for backporting fixes to Cargo is similar bug slightly more
47+
extended than the `rust-lang/rust` repo's procedure. Currently there aren't
48+
backport tags in the Cargo repository, but you'll initiate the backport process
49+
by commenting on an associated PR, requesting a backport. Once a Cargo team
50+
member has approved the backport to happen you're good to start sending PRs!
51+
52+
* First you'll send a PR to the `rust-1.21.0` branch of Cargo (replace 1.21 with
53+
the current rustc beta version number). Like with `rust-lang/rust` you'll
54+
prefix the title of your PR with `[beta]` and ensure it's flagged as going to
55+
beta.
56+
57+
* Next a Cargo reviewer will `@bors: r+` the PR and put it into the queue.
58+
Eventually bors will automatically merge the PR (when tests are passing) to
59+
the appropriate Cargo branch.
60+
61+
* Finally you'll send a PR to the `rust-lang/rust` repository's `beta` branch,
62+
updating the Cargo submodule. The Cargo submodule should be updated to the tip
63+
of the `rust-1.21.0` branch (the branch your Cargo PR was merged to). As like
64+
before, ensure you've got `[beta]` in the PR title.
65+
66+
After that's all said and done the Cargo change is ready to get scheduled onto
67+
the beta release!

0 commit comments

Comments
 (0)