Skip to content

Commit

Permalink
doc: describe labelling process for backports
Browse files Browse the repository at this point in the history
Based on discussion from the first backporting team meeting.

PR-URL: #12431
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Myles Borins <myles.borins@gmail.com>
  • Loading branch information
addaleax authored and MylesBorins committed Aug 16, 2017
1 parent 6e08ae0 commit c3bb07c
Showing 1 changed file with 27 additions and 4 deletions.
31 changes: 27 additions & 4 deletions doc/onboarding-extras.md
Original file line number Diff line number Diff line change
Expand Up @@ -77,6 +77,33 @@ Please use these when possible / appropriate
git checkout $(git show -s --pretty='%T' $(git show-ref -d $(git describe --abbrev=0) | tail -n1 | awk '{print $1}')) -- test; make -j4 test
```

### LTS/Version labels

We use labels to keep track of which branches a commit should land on:

* `dont-land-on-v?.x`
* For changes that do not apply to a certain release line
* Also used when the work of backporting a change outweighs the benefits
* `land-on-v?.x`
* Used by releasers to mark a PR as scheduled for inclusion in an LTS release
* Applied to the original PR for clean cherry-picks, to the backport PR otherwise
* `backport-requested-v?.x`
* Used to indicate that a PR needs a manual backport to a branch in order to land the changes on that branch
* Typically applied by a releaser when the PR does not apply cleanly or it breaks the tests after applying
* Will be replaced by either `dont-land-on-v?.x` or `backported-to-v?.x`
* `backported-to-v?.x`
* Applied to PRs for which a backport PR has been merged
* `lts-watch-v?.x`
* Applied to PRs which the LTS working group should consider including in a LTS release
* Does not indicate that any specific action will be taken, but can be effective as messaging to non-collaborators
* `lts-agenda`
* For things that need discussion by the LTS working group
* (for example semver-minor changes that need or should go into an LTS release)
* `v?.x`
* Automatically applied to changes that do not target `master` but rather the `v?.x-staging` branch

Once a release line enters maintenance mode, the corresponding labels do not
need to be attached anymore, as only important bugfixes will be included.

### Other Labels

Expand All @@ -86,10 +113,6 @@ Please use these when possible / appropriate
* Architecture labels
* `arm`, `mips`
* No x86{_64}, since that is the implied default
* `lts-agenda`, `lts-watch-v*`
* tag things that should be discussed to go into LTS or should go into a specific LTS branch
* (usually only semver-patch things)
* will come more naturally over time


## Updating Node.js from Upstream
Expand Down

0 comments on commit c3bb07c

Please sign in to comment.