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

doc: revise deprecation semverness info in Collaborator Guide

Browse Source 
Simplify and clarify deprecation semverness information in the
Collaborator Guide. Unlike some of the other changes I've made lately,
this one is not merely cosmetic. It changes information about how to
handle deprecations vis-a-vis SemVer. The revised conventions take
advange of `notable change` labels etc. instead of suggesting that
doc-deprecations be treated as `semver-minor`. The idea that a
deprecation is a new feature seems incorrect from a SemVer perspective,
but probably made sense at the time the text was written if we weren't
yet using `notable change` etc.

PR-URL: https://github.com/nodejs/node/pull/26232
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
This commit is contained in:
Rich Trott 2019-02-20 22:30:14 -08:00
parent 4a3928e125
commit 04d5c1b8fd
1 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
COLLABORATOR_GUIDE.md
View File

@ -339,13 +339,13 @@ documentation must state the deprecation status.
* Backward-incompatible changes including complete removal of such APIs may
occur at any time.
Documentation-Only Deprecations may be handled as semver-minor or semver-major
changes. Such deprecations have no impact on the successful operation of running
code and therefore should not be viewed as breaking changes.
Apply the `notable change` label to all pull requests that introduce
Documentation-Only Deprecations. Such deprecations have no impact on code
execution. Thus, they are not breaking changes (`semver-major`).
Runtime Deprecations and End-of-life APIs (internal or public) must be
handled as semver-major changes unless there is TSC consensus to land the
deprecation as a semver-minor.
Runtime Deprecations and End-of-life APIs (internal or public) are breaking
changes (`semver-major`). The TSC may make exceptions, deciding that one of
these deprecations is not a breaking change.
All Documentation-Only and Runtime deprecations will be assigned a unique
identifier that can be used to persistently refer to the deprecation in