From 5511b214171b93182d482a4318eaf2984dcc24f8 Mon Sep 17 00:00:00 2001 From: Jon Moss Date: Mon, 11 Jun 2018 20:56:33 -0400 Subject: [PATCH 1/3] doc: add build wg info to releases.md --- doc/releases.md | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/doc/releases.md b/doc/releases.md index 7e542082224623..0bf7029a11b9ac 100644 --- a/doc/releases.md +++ b/doc/releases.md @@ -81,6 +81,19 @@ Notes: - Version strings are listed below as _"vx.y.z"_. Substitute for the release version. +### 0. Pre-release steps + +Before preparing a Node.js release, you must notify the Build Working Group at +least twenty-four hours in advance of the expected release. Coordinating with +Build is essential to make sure that the CI works, release files are published, +and the release blog post is available on the project website. + +When preparing a security release, contact Build at least forty-eight hours in +advance of the expected release. To ensure that the security patch(es) can be +properly tested, run a `node-test-pull-request` job against the `master` branch +of the `nodejs-private/node-private` repository a day or so before the +[CI lockdown procedure][] begins. + ### 1. Cherry-picking from `master` and other branches Create a new branch named _"vx.y.z-proposal"_, or something similar. Using `git @@ -517,4 +530,5 @@ Close your release proposal PR and remove the proposal branch. _In whatever form you do this..._ +[CI lockdown procedure]: https://github.com/nodejs/build/blob/master/doc/jenkins-guide.md#restricting-access-for-security-releases [nodejs.org release-post.js script]: https://github.com/nodejs/nodejs.org/blob/master/scripts/release-post.js From 73374c41c510c6571eaea8692c293dc41495ee77 Mon Sep 17 00:00:00 2001 From: Jon Moss Date: Mon, 11 Jun 2018 21:55:10 -0400 Subject: [PATCH 2/3] [squash] add "how" --- doc/releases.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/doc/releases.md b/doc/releases.md index 0bf7029a11b9ac..5aefa26a5685c3 100644 --- a/doc/releases.md +++ b/doc/releases.md @@ -88,6 +88,9 @@ least twenty-four hours in advance of the expected release. Coordinating with Build is essential to make sure that the CI works, release files are published, and the release blog post is available on the project website. +Build can be contacted best by opening up an issue on the [issue tracker][], +and by posting in `#node-build` on [webchat.freenode.net][]. + When preparing a security release, contact Build at least forty-eight hours in advance of the expected release. To ensure that the security patch(es) can be properly tested, run a `node-test-pull-request` job against the `master` branch @@ -531,4 +534,6 @@ Close your release proposal PR and remove the proposal branch. _In whatever form you do this..._ [CI lockdown procedure]: https://github.com/nodejs/build/blob/master/doc/jenkins-guide.md#restricting-access-for-security-releases +[issue tracker]: https://github.com/nodejs/build/issues/new [nodejs.org release-post.js script]: https://github.com/nodejs/nodejs.org/blob/master/scripts/release-post.js +[webchat.freenode.net]: https://webchat.freenode.net/ From 3506130ef400b25e9d21d83ec7a5142e334e89e5 Mon Sep 17 00:00:00 2001 From: Jon Moss Date: Tue, 12 Jun 2018 09:39:32 -0400 Subject: [PATCH 3/3] [squash] nits --- doc/releases.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/doc/releases.md b/doc/releases.md index 5aefa26a5685c3..902547ef994069 100644 --- a/doc/releases.md +++ b/doc/releases.md @@ -83,19 +83,20 @@ Notes: ### 0. Pre-release steps -Before preparing a Node.js release, you must notify the Build Working Group at -least twenty-four hours in advance of the expected release. Coordinating with +Before preparing a Node.js release, the Build Working Group must be notified at +least one business day in advance of the expected release. Coordinating with Build is essential to make sure that the CI works, release files are published, and the release blog post is available on the project website. -Build can be contacted best by opening up an issue on the [issue tracker][], +Build can be contacted best by opening up an issue on the [Build issue tracker][], and by posting in `#node-build` on [webchat.freenode.net][]. -When preparing a security release, contact Build at least forty-eight hours in +When preparing a security release, contact Build at least two weekdays in advance of the expected release. To ensure that the security patch(es) can be properly tested, run a `node-test-pull-request` job against the `master` branch of the `nodejs-private/node-private` repository a day or so before the -[CI lockdown procedure][] begins. +[CI lockdown procedure][] begins. This is to confirm that Jenkins can properly +access the private repository. ### 1. Cherry-picking from `master` and other branches @@ -534,6 +535,6 @@ Close your release proposal PR and remove the proposal branch. _In whatever form you do this..._ [CI lockdown procedure]: https://github.com/nodejs/build/blob/master/doc/jenkins-guide.md#restricting-access-for-security-releases -[issue tracker]: https://github.com/nodejs/build/issues/new +[Build issue tracker]: https://github.com/nodejs/build/issues/new [nodejs.org release-post.js script]: https://github.com/nodejs/nodejs.org/blob/master/scripts/release-post.js [webchat.freenode.net]: https://webchat.freenode.net/