doc: include security release proposal tutorial

[RafaelGSS]

While creating the next proposal. I missed a document containing a tutorial and as mentioned in the nodejs/Release#758 meeting, looks reasonable to have a section covering that.

[nodejs-github-bot]

Review requested:

• @nodejs/tsc

[mhdawson]

I think a reference in the section that says * [ ] The releaser(s) run the release process to completion. to the new section would make sense.

[BethGriggs]

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!

[mhdawson]

@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.

[RafaelGSS]

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.

[BethGriggs]

I feel pretty strongly that this should be in releases.md and not in security-release-process.md. We already have steps in releases.md which cover security specifics, and I think we just need to highlight the ones that are missing (which you've covered in this PR).

Another reason I think this shouldn't be in security-release-process.md is because at the moment that document contains just the instructions for the security steward - the security steward doesn't need to care about the mechanics of the release process.

[BethGriggs]

ping @nodejs/releasers

[RafaelGSS]

I feel pretty strongly that this should be in releases.md and not in security-release-process.md. We already have steps in releases.md which cover security specifics, and I think we just need to highlight the ones that are missing (which you've covered in this PR).

Another reason I think this shouldn't be in security-release-process.md is because at the moment that document contains just the instructions for the security steward - the security steward doesn't need to care about the mechanics of the release process.

Let me give a shot moving the content to the releases.md

[RafaelGSS]

Closed in favor of #43835