Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

doc: add build wg info to releases.md #21275

Closed
wants to merge 3 commits into from
Closed

doc: add build wg info to releases.md #21275

Changes from 2 commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
5511b21
doc: add build wg info to releases.md
maclover7 Jun 12, 2018
73374c4
[squash] add "how"
maclover7 Jun 12, 2018
3506130
[squash] nits
maclover7 Jun 12, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 19 additions & 0 deletions doc/releases.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -81,6 +81,22 @@ 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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd /s/must/should.

Also drop a line about "how", i.e. open an issue in the build repo, and check for responses.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Honestly, I'd rather keep it must. Good idea to add the "how"

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we try to avoid using “you”? So maybe just delete “you must” together and it means basically the same

least twenty-four hours in advance of the expected release. Coordinating with
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe twenty-four hours -> one business day so that weekend days don't count?

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][],
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the issue tracker -> 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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

forty-eight hours -> two business days?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like these changes though they are tricky - maybe week day since there might be holidays based on locale?

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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would running a node-test-pull-request job expose sensitive information on CI?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No -- the idea is to run a CI job against the master branch of nodejs-private/node-private (all sec stuff should be done via PRs like we do for nodejs/node) just to verify the jobs can even access the private repo. Last night, all Jenkins jobs could not access the private repo and each had to updated manually.


### 1. Cherry-picking from `master` and other branches

Create a new branch named _"vx.y.z-proposal"_, or something similar. Using `git
Expand Down Expand Up @@ -517,4 +533,7 @@ 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/