diff options
| author | Rich Trott <rtrott@gmail.com> | 2019-01-30 22:02:06 -0800 |
|---|---|---|
| committer | Rich Trott <rtrott@gmail.com> | 2019-02-01 23:44:34 -0800 |
| commit | 28c0f84a695790109c6f863986feae2726374fa5 (patch) | |
| tree | 6a125e90ab5c47a70d15967f93629923577dafa4 /COLLABORATOR_GUIDE.md | |
| parent | 8198ca0b268d765a4c8b0b3e784abc4c8857824b (diff) | |
| download | android-node-v8-28c0f84a695790109c6f863986feae2726374fa5.tar.gz android-node-v8-28c0f84a695790109c6f863986feae2726374fa5.tar.bz2 android-node-v8-28c0f84a695790109c6f863986feae2726374fa5.zip | |
doc: remove redundant LTS/Current information in Collaborator Guide
Remove bullet points about how breaking changes are handled in Current
and LTS branches.
* This information is covered in
https://github.com/nodejs/Release#release-plan.
* Having it here and in the above link means that the two may get out of
sync, resulting in confusion.
* The above link appears later in the doc in the LTS section.
* Most Collaborators should not land *anything* in LTS branches and will
almost never have a reason to land things into Current branches. They
land stuff on the master branch. Adding this material here is
confusing because it implies that Collaborators do land stuff on those
branches. Save talk about those branches and how they're managed for
later in the LTS section where it can be made clear that most
Collaborators should not be landing code there anyway.
PR-URL: https://github.com/nodejs/node/pull/25842
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Diffstat (limited to 'COLLABORATOR_GUIDE.md')
| -rw-r--r-- | COLLABORATOR_GUIDE.md | 8 |
1 files changed, 0 insertions, 8 deletions
diff --git a/COLLABORATOR_GUIDE.md b/COLLABORATOR_GUIDE.md index acc8538219..3471ab4aac 100644 --- a/COLLABORATOR_GUIDE.md +++ b/COLLABORATOR_GUIDE.md @@ -278,14 +278,6 @@ providing a Public API in such cases. #### When Breaking Changes Actually Break Things -* Breaking changes should *never* land in Current or LTS except when: - * Resolving critical security issues. - * Fixing a critical bug (e.g. fixing a memory leak) requires a breaking - change. -* If a breaking commit does accidentally land in a Current or LTS branch, an - attempt to fix the issue will be made before the next release; If no fix is - provided then the commit will be reverted. - When any changes are landed on the master branch and it is determined that the changes *do* break existing code, a decision may be made to revert those changes either temporarily or permanently. However, the decision to revert or |