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

doc: revise "Breaking Changes and Deprecations"

Browse Source 
Revise the "Breaking Changes and Deprecations" section of the
Collaborator Guide. Simplify the text. Remove redundant text. The
"Deprecations" section is thorough and linked to from this section.

PR-URL: https://github.com/nodejs/node/pull/25116
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Anto Aravinth <anto.aravinth.cse@gmail.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
This commit is contained in:
Rich Trott 2018-12-18 14:54:00 -08:00
parent 845fdd02f4
commit 966a2df0f6
1 changed files with 6 additions and 23 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

29
COLLABORATOR_GUIDE.md
View File

@ -256,31 +256,14 @@ Examples of breaking changes include:
#### Breaking Changes and Deprecations
With a few exceptions outlined below, when backward-incompatible changes to a
*Public* API are necessary, the existing API *must* be deprecated *first* and
the new API either introduced in parallel or added after the next major Node.js
version following the deprecation as a replacement for the deprecated API. In
other words, as a general rule, existing *Public* APIs *must not* change (in a
backward-incompatible way) without a deprecation.
Existing stable public APIs that change in a backward-incompatible way must
undergo deprecation. The exceptions to this rule are:
Exceptions to this rule may be made in the following cases:
* Adding or removing errors thrown or reported by a Public API;
* Adding or removing errors thrown or reported by a public API;
* Changing error messages for errors without error code;
* Altering the timing and non-internal side effects of the Public API.
Such changes *must* be handled as semver-major changes but MAY be landed
without a [Deprecation cycle](#deprecation-cycle).
Note that errors thrown, along with behaviors and APIs implemented by
dependencies of Node.js (e.g. those originating from V8) are generally not
under the control of Node.js and therefore *are not directly subject to this
policy*. However, care should still be taken when landing updates to
dependencies when it is known or expected that breaking changes to error
handling may have been made. Additional CI testing may be required.
From time-to-time, in particularly exceptional cases, the TSC may be asked to
consider and approve additional exceptions to this rule.
* Altering the timing and non-internal side effects of the public API;
* Changes to errors thrown by dependencies of Node.js, such as V8;
* One-time exceptions granted by the TSC.
For more information, see [Deprecations](#deprecations).