I'm still thinking this content should be in releases.md, with a reference in this file to follow the security release steps. I think maintaining the actual mechanics of release creation in two separate files will be make it more likely for them to become out-of-sync.

We also already have some of the security-specific information in releases.md (such as in https://github.com/nodejs/node/blob/main/doc/contributing/releases.md#5-create-release-commit), so at the moment this would duplicate it.

The actual steps look good though and useful to add though - thanks for writing them down!

@BethGriggs I was kind of thinking the same thing but was happy to defer to what the release team thinks is best. I think having this closer to the other doc for creating releases makes sense to me, and then having a link in this doc to point to that section.

Actually, this document points to the releases.md as a reference too. I've felt a very bad experience when the document tells you to go to another document and then back to the original one. For instance, this document contains:

2. Create a new branch for the release

Then as usual, create the proposal branch:

$ git checkout -b vXX.X.X-proposal

Which could be easily changed to

2. Create a new branch for the release

See: https://github.com/nodejs/node/blob/main/doc/contributing/releases.md#2-create-a-new-branch-for-the-release

However, IMHO it makes the experience very bad and subjective to mistakes, for instance, I'll follow the releases.md in a security release, which might eventually leak sensitive information.

The major problem I see in having two documents is to keep them synced. But, I don't see the releases.md changing too much making the sync hard.