diff --git a/COLLABORATOR_GUIDE.md b/COLLABORATOR_GUIDE.md index bded8a56d5c5d4..cf73f12016f9b3 100644 --- a/COLLABORATOR_GUIDE.md +++ b/COLLABORATOR_GUIDE.md @@ -8,7 +8,7 @@ - [Internal vs. Public API](#internal-vs-public-api) - [Breaking Changes](#breaking-changes) - [Deprecations](#deprecations) - - [Involving the TSC](#involving-the-TSC) + - [Involving the TSC](#involving-the-tsc) * [Landing Pull Requests](#landing-pull-requests) - [Technical HOWTO](#technical-howto) - [I Just Made a Mistake](#i-just-made-a-mistake) @@ -367,7 +367,7 @@ The TSC should serve as the final arbiter where required. ## Landing Pull Requests -* Please never use GitHub's green ["Merge Pull Request"](https://help.github.com/articles/merging-a-pull-request/#merging-a-pull-request-using-the-github-web-interface) button. +* Please never use GitHub's green ["Merge Pull Request"](https://help.github.com/articles/merging-a-pull-request/#merging-a-pull-request-on-github) button. * If you do, please force-push removing the merge. * Reasons for not using the web interface button: * The merge method will add an unnecessary merge commit. @@ -394,8 +394,8 @@ information regarding the change process: - Useful for @mentions / contact list if something goes wrong in the PR. - Protects against the assumption that GitHub will be around forever. -Review the commit message to ensure that it adheres to the guidelines -outlined in the [contributing](./CONTRIBUTING.md#step-3-commit) guide. +Review the commit message to ensure that it adheres to the guidelines outlined +in the [contributing](./CONTRIBUTING.md#commit-message-guidelines) guide. See the commit log for examples such as [this one](https://github.com/nodejs/node/commit/b636ba8186) if unsure @@ -520,7 +520,7 @@ commit message for that commit. This is a good moment to fix incorrect commit logs, ensure that they are properly formatted, and add `Reviewed-By` lines. * The commit message text must conform to the -[commit message guidelines](./CONTRIBUTING.md#step-3-commit). +[commit message guidelines](./CONTRIBUTING.md#commit-message-guidelines). Run tests (`make -j4 test` or `vcbuild test`). Even though there was a successful continuous integration run, other changes may have landed on master @@ -594,7 +594,8 @@ commit final. Long Term Support (often referred to as *LTS*) guarantees application developers a 30 month support cycle with specific versions of Node.js. -You can find more information [in the full LTS plan](https://github.com/nodejs/lts#lts-plan). +You can find more information +[in the full release plan](https://github.com/nodejs/Release#release-plan). #### How does LTS work? @@ -674,5 +675,5 @@ release. This process of making a release will be a collaboration between the LTS working group and the Release team. [backporting guide]: doc/guides/backporting-to-release-lines.md -[Stability Index]: https://github.com/nodejs/node/pull/doc/api/documentation.md#stability-index +[Stability Index]: doc/api/documentation.md#stability-index [Enhancement Proposal]: https://github.com/nodejs/node-eps diff --git a/doc/guides/backporting-to-release-lines.md b/doc/guides/backporting-to-release-lines.md index 4b5694f0ad486d..9f48d940cd128f 100644 --- a/doc/guides/backporting-to-release-lines.md +++ b/doc/guides/backporting-to-release-lines.md @@ -6,7 +6,7 @@ Each release line has a staging branch that the releaser will use as a scratch pad while preparing a release. The branch name is formatted as follows: `vN.x-staging` where `N` is the major release number. -*Note*: For the active staging branches see the [LTS Schedule][]. +*Note*: For the active staging branches see the [Release Schedule][]. ## What needs to be backported? @@ -19,7 +19,7 @@ requesting that a backport pull request be made. ## What can be backported? The "Current" release line is much more lenient than the LTS release lines in -what can be landed. Our LTS release lines (see the [LTS Plan][]) +what can be landed. Our LTS release lines (see the [Release Plan][]) require that commits mature in the Current release for at least 2 weeks before they can be landed in an LTS staging branch. Only after "maturation" will those commits be cherry-picked or backported. @@ -81,6 +81,6 @@ hint: and commit the result with 'git commit' After the PR lands replace the `backport-requested-v6.x` label on the original PR with `backported-to-v6.x`. -[LTS Schedule]: https://github.com/nodejs/LTS/#lts-schedule1 -[LTS Plan]: https://github.com/nodejs/LTS#lts-plan +[Release Schedule]: https://github.com/nodejs/Release#release-schedule1 +[Release Plan]: https://github.com/nodejs/Release#release-plan [`node-test-pull-request`]: https://ci.nodejs.org/job/node-test-pull-request/build diff --git a/doc/releases.md b/doc/releases.md index d1eeb05876085c..b555cf4136a789 100644 --- a/doc/releases.md +++ b/doc/releases.md @@ -291,7 +291,7 @@ If you didn't wait for ARM builds in the previous step before promoting the rele ### 13. Check the Release -Your release should be available at and . Check that the appropriate files are in place. You may want to check that the binaries are working as appropriate and have the right internal version strings. Check that the API docs are available at . Check that the release catalog files are correct at and . +Your release should be available at `https://nodejs.org/dist/vx.y.z/` and . Check that the appropriate files are in place. You may want to check that the binaries are working as appropriate and have the right internal version strings. Check that the API docs are available at . Check that the release catalog files are correct at and . ### 14. Create a Blog Post @@ -312,7 +312,7 @@ Refs: ### 15. Announce -The nodejs.org website will automatically rebuild and include the new version. To announce the build on Twitter through the official @nodejs account, email [pr@nodejs.org](pr@nodejs.org) with a message such as: +The nodejs.org website will automatically rebuild and include the new version. To announce the build on Twitter through the official @nodejs account, email [pr@nodejs.org](mailto:pr@nodejs.org) with a message such as: > v5.8.0 of @nodejs is out: https://nodejs.org/en/blog/release/v5.8.0/ … something here about notable changes