1berry/nodejs
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

doc: edit LTS material in Collaborator Guide

Browse Source 
* Rewrite some material for simplicity and directness.
* Remove outdated LTS material in the Collaborator Guide. (For example,
  refers to LTS WG for things that are now handled by the Release WG.)
* Minor change to text about force pushing (s/minimize/reduce/).

PR-URL: https://github.com/nodejs/node/pull/26845
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Daijiro Wachi <daijiro.wachi@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
This commit is contained in:
Rich Trott 2019-03-21 13:40:09 -07:00
parent ed849f812d
commit 683e01b250
1 changed files with 11 additions and 27 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

38
COLLABORATOR_GUIDE.md
View File

@ -629,8 +629,8 @@ git push upstream master
messages. You are only allowed to force push to any Node.js branch within 10 messages. You are only allowed to force push to any Node.js branch within 10
minutes from your original push. If someone else pushes to the branch or the minutes from your original push. If someone else pushes to the branch or the
10-minute period passes, consider the commit final. 10-minute period passes, consider the commit final.
* Use `--force-with-lease` to minimize the chance of overwriting * Use `--force-with-lease` to reduce the chance of overwriting someone else's
someone else's change. change.
* Post to `#node-dev` (IRC) if you force push. * Post to `#node-dev` (IRC) if you force push.
### Long Term Support ### Long Term Support
@ -643,35 +643,19 @@ versions. You can find more information
a branch enters LTS, the release plan limits the types of changes permitted in a branch enters LTS, the release plan limits the types of changes permitted in
the branch. the branch.
#### Landing semver-minor commits in LTS
The default policy is to not land semver-minor or higher commits in any LTS
branch. However, the LTS WG or TSC can evaluate any individual semver-minor
commit and decide whether a special exception ought to be made. It is
expected that such exceptions would be evaluated, in part, on the scope
and impact of the changes on the code, the risk to ecosystem stability
incurred by accepting the change, and the expected benefit that landing the
commit will have for the ecosystem.
Any Collaborator who feels a semver-minor commit should be landed in an LTS
branch should attach the `lts-agenda` label to the pull request. The LTS WG
will discuss the issue and, if necessary, will escalate the issue up to the
TSC for further discussion.
#### How are LTS Branches Managed? #### How are LTS Branches Managed?
There are multiple LTS branches, e.g. `v10.x` and `v8.x`. Each of these is Each LTS release has a corresponding branch (v10.x, v8.x, etc.). Each also has a
paired with a staging branch: `v10.x-staging` and `v8.x-staging`. corresponding staging branch (v10.x-staging, v8.x-staging, etc.).
As commits land on the master branch, they are cherry-picked back to each Commits that land on master are cherry-picked to each staging branch as
staging branch as appropriate. If the commit applies only to the LTS branch, the appropriate. If a change applies only to the LTS branch, open the PR against the
PR must be opened against the *staging* branch. Commits are selectively *staging* branch. Commits from the staging branch land on the LTS branch only
pulled from the staging branch into the LTS branch only when a release is when a release is being prepared. They may land on the LTS branch in a different
being prepared and may be pulled into the LTS branch in a different order order than they were in staging.
than they were landed in staging.
Only the members of the @nodejs/backporters team should land commits onto Only members of @nodejs/backporters should land commits onto LTS staging
LTS staging branches. branches.
#### How can I help? #### How can I help?