|
17 | 17 | - [Breaking Changes](#breaking-changes)
|
18 | 18 | - [Breaking Changes and Deprecations](#breaking-changes-and-deprecations)
|
19 | 19 | - [Breaking Changes to Internal Elements](#breaking-changes-to-internal-elements)
|
20 |
| - - [When Breaking Changes Actually Break Things](#when-breaking-changes-actually-break-things) |
| 20 | + - [Unintended Breaking Changes](#unintended-breaking-changes) |
21 | 21 | - [Reverting commits](#reverting-commits)
|
22 | 22 | - [Introducing New Modules](#introducing-new-modules)
|
23 | 23 | - [Additions to N-API](#additions-to-n-api)
|
@@ -276,14 +276,12 @@ an effort to determine the potential impact of the change in the ecosystem. Use
|
276 | 276 | If a change will cause ecosystem breakage, then it is semver-major. Consider
|
277 | 277 | providing a Public API in such cases.
|
278 | 278 |
|
279 |
| -#### When Breaking Changes Actually Break Things |
| 279 | +#### Unintended Breaking Changes |
280 | 280 |
|
281 |
| -When any changes are landed on the master branch and it is determined that the |
282 |
| -changes *do* break existing code, a decision may be made to revert those |
283 |
| -changes either temporarily or permanently. However, the decision to revert or |
284 |
| -not can often be based on many complex factors that are not easily codified. It |
285 |
| -is also possible that the breaking commit can be labeled retroactively as a |
286 |
| -semver-major change that will not be backported to Current or LTS branches. |
| 281 | +Sometimes, a change intended to be non-breaking turns out to be a breaking |
| 282 | +change. If such a change lands on the master branch, a Collaborator may revert |
| 283 | +it. As an alternative to reverting, the TSC may apply the semver-major label |
| 284 | +after-the-fact. |
287 | 285 |
|
288 | 286 | ##### Reverting commits
|
289 | 287 |
|
|
0 commit comments