From fb786e7f9a396029ffa883a6062149adac936e4c Mon Sep 17 00:00:00 2001 From: Aviv Keller <38299977+RedYetiDev@users.noreply.github.com> Date: Sat, 6 Jul 2024 17:15:12 -0400 Subject: [PATCH 01/10] doc: change backporting guide with updated info --- .../backporting-to-release-lines.md | 146 +++++++----------- 1 file changed, 52 insertions(+), 94 deletions(-) diff --git a/doc/contributing/backporting-to-release-lines.md b/doc/contributing/backporting-to-release-lines.md index 851e4e255442d1..f849295cbbfa0e 100644 --- a/doc/contributing/backporting-to-release-lines.md +++ b/doc/contributing/backporting-to-release-lines.md @@ -2,133 +2,91 @@ ## Staging branches -Each release line has a staging branch that the releaser will use as a scratch -pad while preparing a release. The branch name is formatted as follows: -`vN.x-staging` where `N` is the major release number. +Each release line has a staging branch that serves as a workspace for preparing releases. The branch format is `vN.x-staging`, where `N` is the major release number. -For the active staging branches see the [Release Schedule][]. +For active staging branches, refer to the [Release Schedule][]. -## What needs to be backported? +## Identifying backport needs -If a cherry-pick from `main` does not land cleanly on a staging branch, the -releaser will mark the pull request with a particular label for that release -line (e.g. `backport-requested-vN.x`), specifying to our tooling that this -pull request should not be included. The releaser will then add a comment -requesting that a backport pull request be made. +If a cherry-pick from `main` doesn't merge cleanly with a staging branch, the pull request will be labeled for the release line (e.g., `backport-requested-vN.x`). This indicates that manual backporting is required. -## What can be backported? +## Criteria for backporting -The "Current" release line is much more lenient than the LTS release lines in -what can be landed. Our LTS release lines (see the [Release Plan][]) -require that commits mature in the Current release for at least 2 weeks before -they can be landed in an LTS staging branch. Only after "maturation" will those -commits be cherry-picked or backported. +The "Current" release line is more flexible than LTS lines. LTS branches, detailed in the [Release Plan][], require commits to mature in the Current release for at least two weeks before backporting. -## How to label backport issues and PRs? +## Labeling backport issues and PRs -For the following labels, the `N` in `vN.x` refers to the major release number. +Use the following labels, with `N` in `vN.x` denoting the major release number: -| Label | Description | -| ----------------------- | ------------------------------------------------------------------------------------------------- | -| backport-blocked-vN.x | PRs that should land on the vN.x-staging branch but are blocked by another PR's pending backport. | -| backport-open-vN.x | Indicate that the PR has an open backport. | -| backport-requested-vN.x | PRs awaiting manual backport to the vN.x-staging branch. | -| backported-to-vN.x | PRs backported to the vN.x-staging branch. | -| baking-for-lts | PRs that need to wait before landing in a LTS release. | -| lts-watch-vN.x | PRs that may need to be released in vN.x. | -| vN.x | Issues that can be reproduced on vN.x or PRs targeting the vN.x-staging branch. | +| Label | Description | +| ----------------------- | ------------------------------------------------------------------- | +| backport-blocked-vN.x | PRs for `vN.x-staging` blocked by pending backports from other PRs. | +| backport-open-vN.x | Indicates an open backport for the PR. | +| backport-requested-vN.x | PR awaiting manual backport to `vN.x-staging`. | +| backported-to-vN.x | PR successfully backported to `vN.x-staging`. | +| baking-for-lts | PRs awaiting LTS release after maturation in Current. | +| lts-watch-vN.x | PRs possibly included in `vN.x` LTS releases. | +| vN.x | Issues or PRs impacting `vN.x-staging` (or reproducible on vN.x). | -## How to submit a backport pull request +## Submitting a backport pull request -For the following steps, let's assume that you need to backport PR `123` -to the v20.x release line. All commands will use the `v20.x-staging` branch -as the target branch. In order to submit a backport pull request to another -branch, simply replace that with the staging branch for the targeted release -line. +Follow these steps to backport a PR (e.g., #123) to the `vN.x` release line: -### Automated +### Automated process -1. Make sure you have [`@node-core/utils`][] installed +1. Ensure [`@node-core/utils`][] is installed. -2. Run the [`git node backport`][] command +2. Execute [`git node backport`][] command: -```bash -# Backport PR 123 to v20.x-staging -git node backport 123 --to=20 -``` + ```bash + # Example: Backport PR 123 to vN.x-staging + git node backport 123 --to=N + ``` -3. Jump to step 5 in the Manual section below +3. Proceed to step 5 in the Manual section below. -### Manually +### Manual process -1. Checkout the staging branch for the targeted release line. +1. Check out the `vN.x-staging` branch. -2. Make sure that the local staging branch is up to date with the remote. +2. Update the local staging branch from the remote. -3. Create a new branch off of the staging branch, as shown below. +3. Create a new branch based on `vN.x-staging`: ```bash - # Assuming your fork of Node.js is checked out in $NODE_DIR, - # the origin remote points to your fork, and the upstream remote points - # to git@github.com:nodejs/node.git - cd $NODE_DIR - # If v20.x-staging is checked out `pull` should be used instead of `fetch` git fetch upstream v20.x-staging:v20.x-staging -f - # Assume we want to backport PR #10157 - git checkout -b backport-10157-to-v20.x v20.x-staging - # Ensure there are no test artifacts from previous builds - # Note that this command deletes all files and directories - # not under revision control below the ./test directory. - # It is optional and should be used with caution. - git clean -xfd ./test/ + git checkout -b backport-123-to-v20.x v20.x-staging ``` -4. After creating the branch, apply the changes to the branch. The cherry-pick - will likely fail due to conflicts. In that case, you will see something - like this: +4. Resolve conflicts during cherry-pick: ```console - # Say the $SHA is 773cdc31ef - $ git cherry-pick $SHA # Use your commit hash - error: could not apply 773cdc3... - hint: after resolving the conflicts, mark the corrected paths - hint: with 'git add ' or 'git rm ' - hint: and commit the result with 'git commit' + git cherry-pick ``` -5. Make the required changes to remove the conflicts, add the files to the index - using `git add`, and then commit the changes. That can be done with - `git cherry-pick --continue`. +5. Resolve conflicts using `git add` and `git cherry-pick --continue`. -6. Leave the commit message as is. If you think it should be modified, comment - in the pull request. The `Backport-PR-URL` metadata does need to be added to - the commit, but this will be done later. +6. Keep the commit message unchanged or modify as needed. -7. Make sure `make -j4 test` passes. +7. Verify with `make -j4 test`. -8. Push the changes to your fork. +8. Push changes to your fork. 9. Open a pull request: - 1. Be sure to target the `v20.x-staging` branch in the pull request. - 2. Include the backport target in the pull request title in the following - format: `[v20.x backport] `. - Example: `[v20.x backport] process: improve performance of nextTick` - 3. Check the checkbox labeled "Allow edits and access to secrets by - maintainers". - 4. In the description add a reference to the original pull request. - 5. Amend the commit message and include a `Backport-PR-URL:` metadata and - re-push the change to your fork. - 6. Run a [`node-test-pull-request`][] CI job (with `REBASE_ONTO` set to the - default ``) - -10. Replace the `backport-requested-v20.x` label on the original pull request - with `backport-open-v20.x`. - -11. If during the review process conflicts arise, use the following to rebase: - `git pull --rebase upstream v20.x-staging` - -After the pull request lands, replace the `backport-open-v20.x` label on the -original pull request with `backported-to-v20.x`. + + - Target `vN.x-staging`. + - Title format: `[vN.x backport] ` (e.g., `[v20.x backport] process: improve performance of nextTick`). + - Allow maintainer access. + - Reference the original PR in the description. + - Add `Backport-PR-URL:` metadata and re-push. + +10. Run [`node-test-pull-request`][] CI job (with default `REBASE_ONTO`). + +11. Replace `backport-requested-vN.x` with `backport-open-vN.x` on the original PR. + +12. Resolve conflicts with `git pull --rebase upstream vN.x-staging` if needed. + +Once merged, update the original PR's label from `backport-open-vN.x` to `backported-to-vN.x`. [Release Plan]: https://github.com/nodejs/Release#release-plan [Release Schedule]: https://github.com/nodejs/Release#release-schedule From 02c18aef9d7c37c8e69f798663214176ecd8cb01 Mon Sep 17 00:00:00 2001 From: Aviv Keller <38299977+RedYetiDev@users.noreply.github.com> Date: Sat, 6 Jul 2024 17:32:51 -0400 Subject: [PATCH 02/10] lint --- .../backporting-to-release-lines.md | 54 ++++++++++--------- 1 file changed, 29 insertions(+), 25 deletions(-) diff --git a/doc/contributing/backporting-to-release-lines.md b/doc/contributing/backporting-to-release-lines.md index f849295cbbfa0e..ba41a6677dc0cf 100644 --- a/doc/contributing/backporting-to-release-lines.md +++ b/doc/contributing/backporting-to-release-lines.md @@ -1,20 +1,24 @@ -# How to backport a pull request to a release line +# How to Backport a Pull Request to a Release Line -## Staging branches +## Staging Branches -Each release line has a staging branch that serves as a workspace for preparing releases. The branch format is `vN.x-staging`, where `N` is the major release number. +Each release line has a staging branch that serves as a workspace for preparing releases. +The branch format is `vN.x-staging`, where `N` is the major release number. For active staging branches, refer to the [Release Schedule][]. -## Identifying backport needs +## Identifying Backport Needs -If a cherry-pick from `main` doesn't merge cleanly with a staging branch, the pull request will be labeled for the release line (e.g., `backport-requested-vN.x`). This indicates that manual backporting is required. +If a cherry-pick from `main` doesn't merge cleanly with a staging branch, the pull request +will be labeled for the release line (e.g., `backport-requested-vN.x`). This indicates that +manual backporting is required. -## Criteria for backporting +## Criteria for Backporting -The "Current" release line is more flexible than LTS lines. LTS branches, detailed in the [Release Plan][], require commits to mature in the Current release for at least two weeks before backporting. +The "Current" release line is more flexible than LTS lines. LTS branches, detailed in the [Release Plan][], +require commits to mature in the Current release for at least two weeks before backporting. -## Labeling backport issues and PRs +## Labeling Backport Issues and PRs Use the following labels, with `N` in `vN.x` denoting the major release number: @@ -28,30 +32,30 @@ Use the following labels, with `N` in `vN.x` denoting the major release number: | lts-watch-vN.x | PRs possibly included in `vN.x` LTS releases. | | vN.x | Issues or PRs impacting `vN.x-staging` (or reproducible on vN.x). | -## Submitting a backport pull request +## Submitting a Backport Pull Request -Follow these steps to backport a PR (e.g., #123) to the `vN.x` release line: +Follow these steps to backport a PR (e.g., #123) to the `v20.x` release line: -### Automated process +### Automated Process 1. Ensure [`@node-core/utils`][] is installed. 2. Execute [`git node backport`][] command: ```bash - # Example: Backport PR 123 to vN.x-staging - git node backport 123 --to=N + # Example: Backport PR 123 to v20.x-staging + git node backport 123 --to=20 ``` 3. Proceed to step 5 in the Manual section below. -### Manual process +### Manual Process -1. Check out the `vN.x-staging` branch. +1. Check out the `v20.x-staging` branch. 2. Update the local staging branch from the remote. -3. Create a new branch based on `vN.x-staging`: +3. Create a new branch based on `v20.x-staging`: ```bash git fetch upstream v20.x-staging:v20.x-staging -f @@ -61,7 +65,7 @@ Follow these steps to backport a PR (e.g., #123) to the `vN.x` release line: 4. Resolve conflicts during cherry-pick: ```console - git cherry-pick + git cherry-pick $SHA # Use commit hash ``` 5. Resolve conflicts using `git add` and `git cherry-pick --continue`. @@ -74,19 +78,19 @@ Follow these steps to backport a PR (e.g., #123) to the `vN.x` release line: 9. Open a pull request: - - Target `vN.x-staging`. - - Title format: `[vN.x backport] ` (e.g., `[v20.x backport] process: improve performance of nextTick`). - - Allow maintainer access. - - Reference the original PR in the description. - - Add `Backport-PR-URL:` metadata and re-push. + * Target `v20.x-staging`. + * Title format: `[v20.x backport] ` (e.g., `[v20.x backport] process: improve performance of nextTick`). + * Allow maintainer access. + * Reference the original PR in the description. + * Add `Backport-PR-URL:` metadata and re-push. 10. Run [`node-test-pull-request`][] CI job (with default `REBASE_ONTO`). -11. Replace `backport-requested-vN.x` with `backport-open-vN.x` on the original PR. +11. Replace `backport-requested-v20.x` with `backport-open-v20.x` on the original PR. -12. Resolve conflicts with `git pull --rebase upstream vN.x-staging` if needed. +12. Resolve conflicts with `git pull --rebase upstream v20.x-staging` if needed. -Once merged, update the original PR's label from `backport-open-vN.x` to `backported-to-vN.x`. +Once merged, update the original PR's label from `backport-open-v20.x` to `backported-to-v20.x`. [Release Plan]: https://github.com/nodejs/Release#release-plan [Release Schedule]: https://github.com/nodejs/Release#release-schedule From 6f1d67366fee3112ee57a891f7290b2e8d5c8ebf Mon Sep 17 00:00:00 2001 From: Aviv Keller <38299977+RedYetiDev@users.noreply.github.com> Date: Sat, 6 Jul 2024 17:34:14 -0400 Subject: [PATCH 03/10] Update backporting-to-release-lines.md --- .../backporting-to-release-lines.md | 42 +++++++++---------- 1 file changed, 21 insertions(+), 21 deletions(-) diff --git a/doc/contributing/backporting-to-release-lines.md b/doc/contributing/backporting-to-release-lines.md index ba41a6677dc0cf..ae8f9440114e57 100644 --- a/doc/contributing/backporting-to-release-lines.md +++ b/doc/contributing/backporting-to-release-lines.md @@ -1,24 +1,24 @@ -# How to Backport a Pull Request to a Release Line +# How to backport a pull request to a release line -## Staging Branches +## Staging branches Each release line has a staging branch that serves as a workspace for preparing releases. The branch format is `vN.x-staging`, where `N` is the major release number. For active staging branches, refer to the [Release Schedule][]. -## Identifying Backport Needs +## Identifying backport needs If a cherry-pick from `main` doesn't merge cleanly with a staging branch, the pull request -will be labeled for the release line (e.g., `backport-requested-vN.x`). This indicates that -manual backporting is required. +will be labeled for the release line (e.g., `backport-requested-vN.x`). This indicates +that manual backporting is required. -## Criteria for Backporting +## Criteria for backporting The "Current" release line is more flexible than LTS lines. LTS branches, detailed in the [Release Plan][], require commits to mature in the Current release for at least two weeks before backporting. -## Labeling Backport Issues and PRs +## Labeling backport issues and PRs Use the following labels, with `N` in `vN.x` denoting the major release number: @@ -32,30 +32,30 @@ Use the following labels, with `N` in `vN.x` denoting the major release number: | lts-watch-vN.x | PRs possibly included in `vN.x` LTS releases. | | vN.x | Issues or PRs impacting `vN.x-staging` (or reproducible on vN.x). | -## Submitting a Backport Pull Request +## Submitting a backport pull request -Follow these steps to backport a PR (e.g., #123) to the `v20.x` release line: +Follow these steps to backport a PR (e.g., #123) to the `vN.x` release line: -### Automated Process +### Automated process 1. Ensure [`@node-core/utils`][] is installed. 2. Execute [`git node backport`][] command: ```bash - # Example: Backport PR 123 to v20.x-staging - git node backport 123 --to=20 + # Example: Backport PR 123 to vN.x-staging + git node backport 123 --to=N ``` 3. Proceed to step 5 in the Manual section below. -### Manual Process +### Manual process -1. Check out the `v20.x-staging` branch. +1. Check out the `vN.x-staging` branch. 2. Update the local staging branch from the remote. -3. Create a new branch based on `v20.x-staging`: +3. Create a new branch based on `vN.x-staging`: ```bash git fetch upstream v20.x-staging:v20.x-staging -f @@ -65,7 +65,7 @@ Follow these steps to backport a PR (e.g., #123) to the `v20.x` release line: 4. Resolve conflicts during cherry-pick: ```console - git cherry-pick $SHA # Use commit hash + git cherry-pick ``` 5. Resolve conflicts using `git add` and `git cherry-pick --continue`. @@ -78,19 +78,19 @@ Follow these steps to backport a PR (e.g., #123) to the `v20.x` release line: 9. Open a pull request: - * Target `v20.x-staging`. - * Title format: `[v20.x backport] ` (e.g., `[v20.x backport] process: improve performance of nextTick`). + * Target `vN.x-staging`. + * Title format: `[vN.x backport] ` (e.g., `[v20.x backport] process: improve performance of nextTick`). * Allow maintainer access. * Reference the original PR in the description. * Add `Backport-PR-URL:` metadata and re-push. 10. Run [`node-test-pull-request`][] CI job (with default `REBASE_ONTO`). -11. Replace `backport-requested-v20.x` with `backport-open-v20.x` on the original PR. +11. Replace `backport-requested-vN.x` with `backport-open-vN.x` on the original PR. -12. Resolve conflicts with `git pull --rebase upstream v20.x-staging` if needed. +12. Resolve conflicts with `git pull --rebase upstream vN.x-staging` if needed. -Once merged, update the original PR's label from `backport-open-v20.x` to `backported-to-v20.x`. +Once merged, update the original PR's label from `backport-open-vN.x` to `backported-to-vN.x`. [Release Plan]: https://github.com/nodejs/Release#release-plan [Release Schedule]: https://github.com/nodejs/Release#release-schedule From f13012face3f5d8a2388da471886949ab51cf97c Mon Sep 17 00:00:00 2001 From: Aviv Keller <38299977+RedYetiDev@users.noreply.github.com> Date: Mon, 8 Jul 2024 14:37:30 -0400 Subject: [PATCH 04/10] apply suggested changes --- .../backporting-to-release-lines.md | 29 ++++++++++--------- 1 file changed, 15 insertions(+), 14 deletions(-) diff --git a/doc/contributing/backporting-to-release-lines.md b/doc/contributing/backporting-to-release-lines.md index ae8f9440114e57..25cb398a6875ef 100644 --- a/doc/contributing/backporting-to-release-lines.md +++ b/doc/contributing/backporting-to-release-lines.md @@ -9,7 +9,7 @@ For active staging branches, refer to the [Release Schedule][]. ## Identifying backport needs -If a cherry-pick from `main` doesn't merge cleanly with a staging branch, the pull request +If a cherry-pick from `main` doesn't apply cleanly on a staging branch, the pull request will be labeled for the release line (e.g., `backport-requested-vN.x`). This indicates that manual backporting is required. @@ -51,15 +51,15 @@ Follow these steps to backport a PR (e.g., #123) to the `vN.x` release line: ### Manual process -1. Check out the `vN.x-staging` branch. +1. Checkout the `vN.x-staging` branch. -2. Update the local staging branch from the remote. +2. Verify that the local staging branch is up to date with the remote. 3. Create a new branch based on `vN.x-staging`: ```bash - git fetch upstream v20.x-staging:v20.x-staging -f - git checkout -b backport-123-to-v20.x v20.x-staging + git fetch upstream vN.x-staging:vN.x-staging -f + git checkout -b backport-123-to-vN.x vN.x-staging ``` 4. Resolve conflicts during cherry-pick: @@ -70,25 +70,27 @@ Follow these steps to backport a PR (e.g., #123) to the `vN.x` release line: 5. Resolve conflicts using `git add` and `git cherry-pick --continue`. -6. Keep the commit message unchanged or modify as needed. +6. Leave the commit message as is. If you think it should be modified, comment + in the pull request. The `Backport-PR-URL` metadata does need to be added to + the commit, but this will be done later. -7. Verify with `make -j4 test`. +7. Verify that `make -j4 test` passes. -8. Push changes to your fork. +8. Push the changes to your fork. 9. Open a pull request: * Target `vN.x-staging`. * Title format: `[vN.x backport] ` (e.g., `[v20.x backport] process: improve performance of nextTick`). - * Allow maintainer access. * Reference the original PR in the description. - * Add `Backport-PR-URL:` metadata and re-push. -10. Run [`node-test-pull-request`][] CI job (with default `REBASE_ONTO`). +10. Update the `backport-requested-vN.x` label on the original pull request to `backport-open-vN.x`. -11. Replace `backport-requested-vN.x` with `backport-open-vN.x` on the original PR. +11. If conflicts arise during the review process, the following command be used to rebase: -12. Resolve conflicts with `git pull --rebase upstream vN.x-staging` if needed. +```console +git pull --rebase upstream vN.x-staging +``` Once merged, update the original PR's label from `backport-open-vN.x` to `backported-to-vN.x`. @@ -96,4 +98,3 @@ Once merged, update the original PR's label from `backport-open-vN.x` to `backpo [Release Schedule]: https://github.com/nodejs/Release#release-schedule [`@node-core/utils`]: https://github.com/nodejs/node-core-utils [`git node backport`]: https://github.com/nodejs/node-core-utils/blob/main/docs/git-node.md#git-node-backport -[`node-test-pull-request`]: https://ci.nodejs.org/job/node-test-pull-request/build From 8028dd63ef9654fd23e66f0e482fcf2f014ca8f4 Mon Sep 17 00:00:00 2001 From: Aviv Keller <38299977+RedYetiDev@users.noreply.github.com> Date: Mon, 8 Jul 2024 17:36:30 -0400 Subject: [PATCH 05/10] Update backporting-to-release-lines.md Co-authored-by: Antoine du Hamel --- doc/contributing/backporting-to-release-lines.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/doc/contributing/backporting-to-release-lines.md b/doc/contributing/backporting-to-release-lines.md index 25cb398a6875ef..f1ba30a07969b0 100644 --- a/doc/contributing/backporting-to-release-lines.md +++ b/doc/contributing/backporting-to-release-lines.md @@ -34,7 +34,11 @@ Use the following labels, with `N` in `vN.x` denoting the major release number: ## Submitting a backport pull request -Follow these steps to backport a PR (e.g., #123) to the `vN.x` release line: +For the following steps, let's assume that you need to backport PR `123` +to the vN.x release line. All commands will use the `vN.x-staging` branch +as the target branch. In order to submit a backport pull request to another +branch, simply replace `N` with the version number for the targeted release +line. ### Automated process From fbd0135bd2c851a6b77599219fb89f215694aa03 Mon Sep 17 00:00:00 2001 From: Aviv Keller <38299977+RedYetiDev@users.noreply.github.com> Date: Mon, 8 Jul 2024 17:36:40 -0400 Subject: [PATCH 06/10] Update backporting-to-release-lines.md Co-authored-by: Antoine du Hamel --- doc/contributing/backporting-to-release-lines.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/contributing/backporting-to-release-lines.md b/doc/contributing/backporting-to-release-lines.md index f1ba30a07969b0..acdee739537397 100644 --- a/doc/contributing/backporting-to-release-lines.md +++ b/doc/contributing/backporting-to-release-lines.md @@ -66,7 +66,7 @@ line. git checkout -b backport-123-to-vN.x vN.x-staging ``` -4. Resolve conflicts during cherry-pick: +4. Cherry-pick the desired commit(s): ```console git cherry-pick From bbbc64f264034ab7b372d3b615d1bf2f4c0dd77c Mon Sep 17 00:00:00 2001 From: Aviv Keller <38299977+RedYetiDev@users.noreply.github.com> Date: Mon, 8 Jul 2024 17:36:46 -0400 Subject: [PATCH 07/10] Update backporting-to-release-lines.md Co-authored-by: Antoine du Hamel --- doc/contributing/backporting-to-release-lines.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/contributing/backporting-to-release-lines.md b/doc/contributing/backporting-to-release-lines.md index acdee739537397..fc6fc9082550fa 100644 --- a/doc/contributing/backporting-to-release-lines.md +++ b/doc/contributing/backporting-to-release-lines.md @@ -68,7 +68,7 @@ line. 4. Cherry-pick the desired commit(s): - ```console + ```bash git cherry-pick ``` From 4fbd3fea16eb9c69c223f84dae926589ba2f5356 Mon Sep 17 00:00:00 2001 From: Aviv Keller <38299977+RedYetiDev@users.noreply.github.com> Date: Mon, 8 Jul 2024 17:36:54 -0400 Subject: [PATCH 08/10] Update backporting-to-release-lines.md Co-authored-by: Antoine du Hamel --- doc/contributing/backporting-to-release-lines.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/doc/contributing/backporting-to-release-lines.md b/doc/contributing/backporting-to-release-lines.md index fc6fc9082550fa..293012c526afe7 100644 --- a/doc/contributing/backporting-to-release-lines.md +++ b/doc/contributing/backporting-to-release-lines.md @@ -92,9 +92,9 @@ line. 11. If conflicts arise during the review process, the following command be used to rebase: -```console -git pull --rebase upstream vN.x-staging -``` + ```bash + git pull --rebase upstream vN.x-staging + ``` Once merged, update the original PR's label from `backport-open-vN.x` to `backported-to-vN.x`. From 324bb6dd5881b16bee0b0a2a3f987c6aac645f44 Mon Sep 17 00:00:00 2001 From: Aviv Keller <38299977+RedYetiDev@users.noreply.github.com> Date: Fri, 12 Jul 2024 08:00:24 -0400 Subject: [PATCH 09/10] Update backporting-to-release-lines.md --- doc/contributing/backporting-to-release-lines.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/contributing/backporting-to-release-lines.md b/doc/contributing/backporting-to-release-lines.md index 293012c526afe7..d553d42b02759b 100644 --- a/doc/contributing/backporting-to-release-lines.md +++ b/doc/contributing/backporting-to-release-lines.md @@ -7,7 +7,7 @@ The branch format is `vN.x-staging`, where `N` is the major release number. For active staging branches, refer to the [Release Schedule][]. -## Identifying backport needs +## Identifying what requires a backport If a cherry-pick from `main` doesn't apply cleanly on a staging branch, the pull request will be labeled for the release line (e.g., `backport-requested-vN.x`). This indicates From 1e0f0baaeb33bf8d2e4afe6d650758488f202985 Mon Sep 17 00:00:00 2001 From: Aviv Keller <38299977+RedYetiDev@users.noreply.github.com> Date: Fri, 12 Jul 2024 08:31:04 -0400 Subject: [PATCH 10/10] Update backporting-to-release-lines.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Michaël Zasso --- doc/contributing/backporting-to-release-lines.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/contributing/backporting-to-release-lines.md b/doc/contributing/backporting-to-release-lines.md index d553d42b02759b..a1449427cfd92a 100644 --- a/doc/contributing/backporting-to-release-lines.md +++ b/doc/contributing/backporting-to-release-lines.md @@ -7,7 +7,7 @@ The branch format is `vN.x-staging`, where `N` is the major release number. For active staging branches, refer to the [Release Schedule][]. -## Identifying what requires a backport +## Identifying changes that require a backport If a cherry-pick from `main` doesn't apply cleanly on a staging branch, the pull request will be labeled for the release line (e.g., `backport-requested-vN.x`). This indicates