33
33
- [ How is an LTS release cut?] ( #how-is-an-lts-release-cut )
34
34
35
35
This document contains information for Collaborators of the Node.js
36
- project regarding maintaining the code, documentation, and issues .
36
+ project regarding managing the project's code, documentation, and issue tracker .
37
37
38
38
Collaborators should be familiar with the guidelines for new
39
39
contributors in [ CONTRIBUTING.md] ( ./CONTRIBUTING.md ) and also
@@ -206,11 +206,10 @@ Node.js API are internal:
206
206
- Any native C/C++ APIs/ABIs exported by the Node.js ` *.h ` header files that
207
207
are hidden behind the ` NODE_WANT_INTERNALS ` flag are internal.
208
208
209
- Exception to each of these points can be made if use or behavior of a given
210
- internal API can be demonstrated to be sufficiently relied upon by the Node.js
211
- ecosystem such that any changes would cause too much breakage. The threshold
212
- for what qualifies as too much breakage is to be decided on a case-by-case
213
- basis by the TSC.
209
+ Exceptions can be made if use or behavior of a given internal API can be
210
+ demonstrated to be sufficiently relied upon by the Node.js ecosystem such that
211
+ any changes would cause too much breakage. The threshold for what qualifies as
212
+ too much breakage is to be decided on a case-by-case basis by the TSC.
214
213
215
214
If it is determined that a currently undocumented object, property, method,
216
215
argument, or event * should* be documented, then a pull request adding the
@@ -249,14 +248,14 @@ properties to an options argument) are semver-minor changes.
249
248
250
249
#### Breaking Changes and Deprecations
251
250
252
- With a few notable exceptions outlined below, when backwards incompatible
253
- changes to a * Public* API are necessary, the existing API * must* be deprecated
254
- * first * and the new API either introduced in parallel or added after the next
255
- major Node.js version following the deprecation as a replacement for the
256
- deprecated API. In other words, as a general rule, existing * Public* APIs
257
- * must not * change (in a backwards incompatible way) without a deprecation.
251
+ With a few exceptions outlined below, when backward- incompatible changes to a
252
+ * Public* API are necessary, the existing API * must* be deprecated * first * and
253
+ the new API either introduced in parallel or added after the next major Node.js
254
+ version following the deprecation as a replacement for the deprecated API. In
255
+ other words, as a general rule, existing * Public* APIs * must not * change (in a
256
+ backward- incompatible way) without a deprecation.
258
257
259
- Exception to this rule is given in the following cases:
258
+ Exceptions to this rule may be made in the following cases:
260
259
261
260
* Adding or removing errors thrown or reported by a Public API;
262
261
* Changing error messages;
@@ -357,7 +356,7 @@ recommended but not required.
357
356
### Deprecations
358
357
359
358
_ Deprecation_ refers to the identification of Public APIs that should no longer
360
- be used and that may be removed or modified in non-backwards compatible ways in
359
+ be used and that may be removed or modified in backward-incompatible ways in
361
360
a future major release of Node.js. Deprecation may be used with internal APIs if
362
361
there is expected impact on the user community.
363
362
@@ -497,7 +496,7 @@ Check and re-review the changes:
497
496
$ git diff upstream/master
498
497
```
499
498
500
- Check number of commits and commit messages:
499
+ Check the number of commits and commit messages:
501
500
502
501
``` text
503
502
$ git log upstream/master...master
@@ -658,7 +657,7 @@ commit final.
658
657
#### What is LTS?
659
658
660
659
Long Term Support (often referred to as * LTS* ) guarantees application developers
661
- a 30 month support cycle with specific versions of Node.js.
660
+ a 30- month support cycle with specific versions of Node.js.
662
661
663
662
You can find more information
664
663
[ in the full release plan] ( https://github.com/nodejs/Release#release-plan ) .
@@ -671,7 +670,7 @@ certain performance improvements that can be demonstrated to not break existing
671
670
applications. Semver-minor changes are only permitted if required for bug fixes
672
671
and then only on a case-by-case basis with LTS WG and possibly Technical
673
672
Steering Committee (TSC) review. Semver-major changes are permitted only if
674
- required for security related fixes.
673
+ required for security- related fixes.
675
674
676
675
Once a Current branch moves into Maintenance mode, only ** critical** bugs,
677
676
** critical** security fixes, and documentation updates will be permitted.
0 commit comments