Browse files

doc: revise "Breaking Changes and Deprecations"

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: #25116
Reviewed-By: James M Snell <>
Reviewed-By: Anto Aravinth <>
Reviewed-By: Michael Dawson <>
  • Loading branch information...
Trott authored and MylesBorins committed Dec 18, 2018
1 parent 4ca0951 commit 6a690ee51b615cf536f05469a1e3cd7890d67206
Showing with 6 additions and 23 deletions.
  1. +6 −23
@@ -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).

0 comments on commit 6a690ee

Please sign in to comment.