GeezerVison

I don't remember where our documentation says that we should use placeholders for deprecations, but can we change it? We forget to update it way too often and it seems possible to me to have a lint rule to validate the numbers in deprecations.md (no duplicate, sequential).

Collaborators please 👍 to fast track this.

@targos I agree that we should change that. To verify that we have unique codes, we should just add a test that verifies that the codes are unique in our markdown file.

CI: https://ci.nodejs.org/job/node-test-pull-request/31372/

CI: https://ci.nodejs.org/job/node-test-pull-request/31374/ ✅ (all green besides a known CI issue that is unrelated)

Landed in a12a2d8 🎉

Adding the dont-land-on-v14.x label as i did this when i released v14.3.0.

I agree that we should change that. To verify that we have unique codes, we should just add a test that verifies that the codes are unique in our markdown file.

Sidenote: this was actually the intention originally but it never manifested for various reasons. The main difficulty here with deprecation codes is that we do not know when they are actually going to land in a release. What I would prefer is that we just assign the deprecation numbers in the release just like we handle the replaceme tags for versions. We would have to alter the testing strategy somewhat but that's fairly simple.

@jasnell that would not work for backports. It should be possible to just lint for unique deprecation codes. That way we'll immediately know if a PR needs to update before landing.

Well, I'd argue that we likely shouldn't be backporting deprecations but since we stopped requiring doc only deprecations to be major I guess that ship has sailed. Another approach would be to move away from numbered dep codes entirely and use simple labels. DEP_THING style. Lint rules can enforce a style and uniqueness and we can skip the need to apply a sequential numbering at all.