build: add REPLACEME tag for version info in docs

[addaleax]

Checklist

• tests and code linting passes
• the commit message follows commit guidelines

Affected core subsystem(s)

build

Description of change

Add a REPLACEME tag that should be used when introducing docs for new features, so that they can be updated when releases are made. Example usage:

## process.cpuUsage([previousValue])
<!-- YAML
added: REPLACEME
-->

Ref: #6578

@bnoordhuis This is taken straight from #6578 (comment) so I’ve set the commit author to you. I guess that’s okay with you?

[bnoordhuis]

If you go through the trouble of filing the pull request, you can claim authorship. :-)

LGTM either way.

[addaleax]

Credit where credit is due, I’m going to leave it like that. ;)

[claudiorodriguez]

LGTM, should any doc be updated mentioning this?

[addaleax]

@claudiorodriguez Hmm… got any suggestions? It might be nice to make collaborators aware of this in some way, yes.

[claudiorodriguez]

@addaleax right now the added metadata is documented in /tools/doc/README.md so I think it would make sense to add this there. I'd also reference it in CONTRIBUTING.md. Maybe another PR after this one?

[bnoordhuis]

Credit where credit is due, I’m going to leave it like that. ;)

Can you leave my LGTM out in that case? Otherwise I'd show up as both author and reviewer.

[addaleax]

@bnoordhuis Of course, yep.

@claudiorodriguez I’ve added it here… that should be okay. Still LGTY?

[evanlucas]

So, I think it was @Fishrock123 that brought it up, but we should always know that a new feature or method will be going in in the next minor right? Is this still necessary?

[addaleax]

@evanlucas I don’t have strong feelings about it… basically, in my head it’s like this:

Pro REPLACEME:

• People who create PRs don’t need to know when they will land/don’t have to update each time a new minor comes out, if the PR is a bit more long-running
• Replacing REPLACEME in the docs upon release is more or less a single search+replace operation
• (If it’s relevant, this approach may be easier if it comes to backported semver-minor changes)

Contra REPLACEME:

• Extra work during release
• Most of the time it one can make a good guess on the version in which a feature will land

You @nodejs/release people can probably assess things better and if you prefer not to do it this way, that’s perfectly fine.

[evanlucas]

There are definitely pros to this approach. My biggest concern with going this route is how do we make the update permanent? Is that something the releaser should commit and push back up? Otherwise, when we hit the next release, the REPLACEME will be incorrect.

[addaleax]

Would it be okay to do something like this together with/in the release commit? If I’ve understood everything correctly, that one is landed both in the version-specific branch and master.

[evanlucas]

That could work. We do cherry pick the release commit from the release proposal branch back to master. So this will probably work fine for v6, but may become a little hairy for v4. I'm honestly not sure. I do think I'm +1 on this, but really think that all of @nodejs/release should see this before landing. Also, if we add this, we need to make sure that the doc/releases.md document is updated to reflect the process of updating these.

[addaleax]

Yeah, there’s no hurry to implement this process in any case.

And regarding v4.x in general, so far this feature isn’t even implemented there, but I think I’ll do a backporting PR once we’re pretty much through with #6578.

[claudiorodriguez]

@addaleax yep, LGTM on the PR itself. Agree on waiting on more feedback from the release team before landing though

[Fishrock123]

I don't really mind, but I have a question on how this will impact the release process commits-wise...

Currently we do two commits, both of which are the only un-signed-off commits people are regularly allowed to do. (Some leeway is given for if releasers mess up and have to fix links or something afterwards.)

Does this mean we add a third commit before? e.g:

1. Update new API released: info
2. Changelog & node_version.h (This is the tagged commit)
3. Reset node_version.h for the next release

Or do we just roll this into the Changelog commit?

[bnoordhuis]

I don't see anything wrong with rolling it into the Changelog commit.

[addaleax]

Anybody from @nodejs/release want to give their thumbs up for this? :)

[cjihrig]

+1 to rolling it into the Changelog commit. And LGTM

[addaleax]

Landed in 2cd99eb, e7f1c00. Thanks!