doc: clarify that features cannot be both experimental and deprecated#62456
doc: clarify that features cannot be both experimental and deprecated#62456aduh95 wants to merge 2 commits intonodejs:mainfrom
Conversation
|
Review requested:
|
|
Shouldn't there be some way to provide advanced warning? |
wdym? Do you have a scenario in mind? |
| * An improved alternative API is available. | ||
| * Breaking changes to the API are expected in a future major release. | ||
|
|
||
| Deprecated features are subject to [semantic versioning][] rules. |
There was a problem hiding this comment.
I don't think this is the case for the undocumented features being deprecated.
doc/api/documentation.md
Outdated
| > | ||
| > Experimental features leave the experimental status typically either by | ||
| > graduating to stable, or are removed without a deprecation cycle. | ||
| > graduating to stable, by being deprecated, or are removed without a deprecation cycle. |
There was a problem hiding this comment.
Clarifying question: does this mean #62395 (comment) can land because it's doing exactly the newly added exit condition? That is the transition of stability index can be:
- 1 -> 2: stable
- 1 -> 0: deprecated
- 1 -> (black hole?): removed
|
|
|
Changes in |
4 participants
As discussed in the TSC meeting. The rationale is that either an experimental feature can be called experimental only if breaking changes (incl removal) would not break the ecosystem; if removing an experimental feature must go through a deprecation cycle, it is de facto no-longer experimental.