@@ -26,8 +26,8 @@ commits be cherry-picked or backported.
26
26
27
27
## How to submit a backport pull request
28
28
29
- For the following steps, let's assume that a backport is needed for the v8 .x
30
- release line. All commands will use the ` v8 .x-staging` branch as the target
29
+ For the following steps, let's assume that a backport is needed for the v10 .x
30
+ release line. All commands will use the ` v10 .x-staging` branch as the target
31
31
branch. In order to submit a backport pull request to another branch, simply
32
32
replace that with the staging branch for the targeted release line.
33
33
@@ -40,10 +40,10 @@ replace that with the staging branch for the targeted release line.
40
40
# the origin remote points to your fork, and the upstream remote points
41
41
# to git://github.com/nodejs/node
42
42
cd $NODE_DIR
43
- # If v8 .x-staging is checked out `pull` should be used instead of `fetch`
44
- git fetch upstream v8 .x-staging:v8 .x-staging -f
43
+ # If v10 .x-staging is checked out `pull` should be used instead of `fetch`
44
+ git fetch upstream v10 .x-staging:v10 .x-staging -f
45
45
# Assume we want to backport PR #10157
46
- git checkout -b backport-10157-to-v8 .x v8 .x-staging
46
+ git checkout -b backport-10157-to-v10 .x v10 .x-staging
47
47
# Ensure there are no test artifacts from previous builds
48
48
# Note that this command deletes all files and directories
49
49
# not under revision control below the ./test directory.
@@ -73,21 +73,21 @@ replace that with the staging branch for the targeted release line.
73
73
7. Make sure ` make -j4 test` passes.
74
74
8. Push the changes to your fork
75
75
9. Open a pull request:
76
- 1. Be sure to target the ` v8 .x-staging` branch in the pull request.
76
+ 1. Be sure to target the ` v10 .x-staging` branch in the pull request.
77
77
1. Include the backport target in the pull request title in the following
78
- format — ` [v8 .x backport] < commit title> ` .
79
- Example: ` [v8 .x backport] process: improve performance of nextTick`
78
+ format — ` [v10 .x backport] < commit title> ` .
79
+ Example: ` [v10 .x backport] process: improve performance of nextTick`
80
80
1. Check the checkbox labeled " Allow edits from maintainers" .
81
81
1. In the description add a reference to the original PR.
82
82
1. Amend the commit message and include a ` Backport-PR-URL:` metadata and
83
83
re-push the change to your fork.
84
84
1. Run a [` node-test-pull-request` ][] CI job (with ` REBASE_ONTO` set to the
85
85
default ` < pr base branch> ` )
86
86
10. If during the review process conflicts arise, use the following to rebase:
87
- ` git pull --rebase upstream v8 .x-staging`
87
+ ` git pull --rebase upstream v10 .x-staging`
88
88
89
- After the PR lands replace the ` backport-requested-v8 .x` label on the original
90
- PR with ` backported-to-v8 .x` .
89
+ After the PR lands replace the ` backport-requested-v10 .x` label on the original
90
+ PR with ` backported-to-v10 .x` .
91
91
92
92
[Release Schedule]: https://github.com/nodejs/Release#release-schedule1
93
93
[Release Plan]: https://github.com/nodejs/Release#release-plan
0 commit comments