-
Notifications
You must be signed in to change notification settings - Fork 30.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
doc: Update CONTRIBUTING.md with backport info #10343
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -43,8 +43,10 @@ $ git remote add upstream git://github.com/nodejs/node.git | |
|
||
#### Which branch? | ||
|
||
For developing new features and bug fixes, the `master` branch should be pulled | ||
and built upon. | ||
For developing new features and bug fixes, the `master` branch should be | ||
pulled and built upon. See the section on | ||
[backporting](#backporting-to-current-and-lts-branches) if you would like | ||
the fix to be backported to other releases. | ||
|
||
#### Respect the stability index | ||
|
||
|
@@ -322,6 +324,40 @@ doesn't need to wait. A Pull Request may well take longer to be | |
merged in. All these precautions are important because Node.js is | ||
widely used, so don't be discouraged! | ||
|
||
### Backporting to Current and LTS Branches | ||
|
||
Before backporting or contributing to the LTS releases make sure you are | ||
familiar with the [LTS information and schedules](https://github.com/nodejs/LTS#lts-schedule) | ||
|
||
Commits which have already landed on master will be candidates for the | ||
"current" release branch(es) and can then also become candidates for | ||
inclusion into the "Active LTS" branch(es), especially if they are bug | ||
fixes. Any change can be considered for LTS by requesting @nodejs/lts apply | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @nodejs/lts -> a collaborator There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I wanted it to be a bit more specific bearing in mind this should be a fairly self-contained document for beginners. I could point to a list of collaborators and say "Pick a random one from this list" but I would think that this would be a more useful default action for newbies. |
||
the appropriate `lts-watch-vX.x` label for the branch you would like it | ||
backported to. If a commit is not to be considered for backporting please | ||
ask for it to be labelled with `dont-land-on-vX.x`. If it is to be backported | ||
and can be cherry-picked cleanly it will be done by someone from the release | ||
team. Generally all changes should have landed in the current release for | ||
at least two weeks before considering backporting to the LTS releases. | ||
|
||
If a manual backport is required when porting your change to the current or | ||
LTS branches you may be asked to submit a PR against the staging branch of | ||
the release line the backport is targetting `vX.x-staging`. The easiest way | ||
to do the backport this is to use git cherry-pick to pull across the commit | ||
hash from master and manually resolve the conflicts using these commands: | ||
|
||
``` | ||
$ git cherry-pick HASH | ||
// fix all conflicts that are reported | ||
$ git cherry-pick --continue | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. might be worthwhile mentioning that |
||
``` | ||
|
||
When you submit it, please include "vX.x backport" in the PR title. | ||
|
||
If you need to reference other relevant pull requests regarding the | ||
conflicts, list them as "Refs:" links in the PR message. | ||
|
||
|
||
### Check Out the Collaborator's Guide | ||
|
||
If you want to know more about the code review and the landing process, | ||
|
@@ -354,3 +390,4 @@ By making a contribution to this project, I certify that: | |
personal information I submit with it, including my sign-off) is | ||
maintained indefinitely and may be redistributed consistent with | ||
this project or the open source license(s) involved. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The use of "should" in this first sentence has always bothered me. The master branch is the branch for new features and bug fixes, not should be. So perhaps changing this to: