| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
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.
|
@Trott build started: https://ci.nodejs.org/blue/organizations/jenkins/node-test-pull-request-lite-pipeline/detail/node-test-pull-request-lite-pipeline/2682/pipeline |
Sorry, something went wrong.
Co-Authored-By: Trott <rtrott@gmail.com>
Sorry, something went wrong.
| 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 |
There was a problem hiding this comment.
AFAIK we try to add the label to all deprecations - no matter if it's doc-only, runtime or end-of-life.
Sorry, something went wrong.
There was a problem hiding this comment.
Yes, and that's noted on line 371 currently. I'm repeating it here though because Documentation-Only deprecations are the ones most likely to be missed as notable changes. Other ones go in as semver-major so they're likely to be noticed.
Sorry, something went wrong.
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: nodejs#26232 Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
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: #26232 Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
| Back | FazBrowse Home | New Git URL |
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.
Checklist