The process to create a proposal for a Security Release is very similar to the

common release lines. The major difference is that the base repository is [`node-private`](https://github.com/nodejs-private/node-private)

instead of [`node`](https://github.com/nodejs/node).

Once the [previous steps](#planning) were completed, you should be able to

create a proposal against `node-private`.

The first step is to make sure that the

`origin`[\[1\]](#glossary)/`vXX.x-staging`[\[2\]](#glossary) branch is updated:

$ git remote -v

$ git remote update upstream

$ git reset --hard upstream/vXX.x

Then as usual, create the proposal branch:

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

**Important**: if you are using `git cherry-pick $SHA1` you will need to

manually add the `Reviewed-By` and `PR-URL`

metadata as `git node land` doesn't work on `node-private`.

$ git cherry-pick 1b27a7152309aa87993596f3802d472dcb15f439

$ git commit --amend

# add metadata

$ git push origin vXX.X.X-proposal # IMPORTANT: origin is `node-private` not a public fork

See: [releases.md](./releases.md#3-update-srcnode_versionh)

See: [releases.md](./releases.md#4-update-the-changelog)

**Note**: make sure to include the right entry to the `CHANGELOG_Vx.md`.

The new entry should take the following form:

<a id="x.y.x"></a>

This is a security release.

* List interesting changes here

* Particularly changes that are responsible for minor or major version bumps

* Also be sure to look at any changes introduced by dependencies such as npm

* ... and include any notable items from there

* Include the full list of commits since the last release here. Do not include "Working on X.Y.Z+1" commits.

The `CHANGELOG.md`, `doc/changelogs/CHANGELOG_Vx.md`, `src/node_version.h`, and

`REPLACEME` changes should be the final commit that will be tagged for the

release. When committing these to git, use the following message format:

Push the release branch to `nodejs-private/node-private`, not to your own fork.

This allows release branches to more easily be passed between members of the

release team if necessary.

Create a pull request targeting the correct release line. For example, a

`v5.3.0-proposal` PR should target `v5.x`, not `main`. Paste the CHANGELOG

modifications into the body of the PR so that collaborators can see what is

changing. These PRs should be left open for at least 24 hours, and can be

updated as new commits land. If the CHANGELOG pasted into the pull request

is long enough that it slows down the GitHub UI, consider pasting the commits

into `<details>` tags or in follow up comments.

If using the `<details>` tag, use the following format:

<details>

<summary>Commits</summary>

* Full list of commits...

</details>

If you need any additional information about any of the commits, this PR is a

good place to @-mention the relevant contributors.

After opening the PR, update the release commit to include `PR-URL` metadata and

force-push the proposal.