-
Notifications
You must be signed in to change notification settings - Fork 29.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
doc: revise deprecation semverness info in Collaborator Guide #26232
Conversation
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.
Co-Authored-By: Trott <[email protected]>
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AFAIK we try to add the label to all deprecations - no matter if it's doc-only, runtime or end-of-life.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
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 <[email protected]>
Landed in 04d5c1b |
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 <[email protected]>
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 thatdoc-deprecations be treated as
semver-minor
. The idea that adeprecation 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
make -j4 test
(UNIX), orvcbuild test
(Windows) passes