Skip to content
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

Closed
wants to merge 3 commits into from
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
41 changes: 39 additions & 2 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Copy link
Member

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:

New features and bug fixes are landed in `master` first, then backported to release
branches. See the section on [backporting]...

[backporting](#backporting-to-current-and-lts-branches) if you would like
the fix to be backported to other releases.

#### Respect the stability index

Expand Down Expand Up @@ -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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nodejs/lts -> a collaborator

Copy link
Member Author

Choose a reason for hiding this comment

The 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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

might be worthwhile mentioning that git add {fixed-file} is needed before continuing

```

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,
Expand Down Expand Up @@ -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.