1berry/nodejs
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

doc: fix links in some intra-repository docs

Browse Source 
PR-URL: https://github.com/nodejs/node/pull/15675
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
This commit is contained in:
Vse Mozhet Byt 2017-09-29 05:37:51 +03:00 committed by James M Snell
parent cec6e21668
commit 6be96c70f5
3 changed files with 14 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
COLLABORATOR_GUIDE.md
View File

@ -8,7 +8,7 @@
- [Internal vs. Public API](#internal-vs-public-api) - [Internal vs. Public API](#internal-vs-public-api)
- [Breaking Changes](#breaking-changes) - [Breaking Changes](#breaking-changes)
- [Deprecations](#deprecations) - [Deprecations](#deprecations)
- [Involving the TSC](#involving-the-TSC) - [Involving the TSC](#involving-the-tsc)
* [Landing Pull Requests](#landing-pull-requests) * [Landing Pull Requests](#landing-pull-requests)
- [Technical HOWTO](#technical-howto) - [Technical HOWTO](#technical-howto)
- [I Just Made a Mistake](#i-just-made-a-mistake) - [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 ## 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. * If you do, please force-push removing the merge.
* Reasons for not using the web interface button: * Reasons for not using the web interface button:
* The merge method will add an unnecessary merge commit. * 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. - Useful for @mentions / contact list if something goes wrong in the PR.
- Protects against the assumption that GitHub will be around forever. - Protects against the assumption that GitHub will be around forever.
Review the commit message to ensure that it adheres to the guidelines Review the commit message to ensure that it adheres to the guidelines outlined
outlined in the [contributing](./CONTRIBUTING.md#step-3-commit) guide. in the [contributing](./CONTRIBUTING.md#commit-message-guidelines) guide.
See the commit log for examples such as See the commit log for examples such as
[this one](https://github.com/nodejs/node/commit/b636ba8186) if unsure [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 commit logs, ensure that they are properly formatted, and add
`Reviewed-By` lines. `Reviewed-By` lines.
* The commit message text must conform to the * 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 Run tests (`make -j4 test` or `vcbuild test`). Even though there was a
successful continuous integration run, other changes may have landed on master 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 Long Term Support (often referred to as *LTS*) guarantees application developers
a 30 month support cycle with specific versions of Node.js. 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? #### 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. LTS working group and the Release team.
[backporting guide]: doc/guides/backporting-to-release-lines.md [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 [Enhancement Proposal]: https://github.com/nodejs/node-eps

8
doc/guides/backporting-to-release-lines.md
View File

@ -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: pad while preparing a release. The branch name is formatted as follows:
`vN.x-staging` where `N` is the major release number. `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? ## What needs to be backported?
@ -19,7 +19,7 @@ requesting that a backport pull request be made.
## What can be backported? ## What can be backported?
The "Current" release line is much more lenient than the LTS release lines in 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 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 they can be landed in an LTS staging branch. Only after "maturation" will those
commits be cherry-picked or backported. 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 After the PR lands replace the `backport-requested-v6.x` label on the original
PR with `backported-to-v6.x`. PR with `backported-to-v6.x`.
[LTS Schedule]: https://github.com/nodejs/LTS/#lts-schedule1 [Release Schedule]: https://github.com/nodejs/Release#release-schedule1
[LTS Plan]: https://github.com/nodejs/LTS#lts-plan [Release Plan]: https://github.com/nodejs/Release#release-plan
[`node-test-pull-request`]: https://ci.nodejs.org/job/node-test-pull-request/build [`node-test-pull-request`]: https://ci.nodejs.org/job/node-test-pull-request/build

4
doc/releases.md
View File

@ -291,7 +291,7 @@ If you didn't wait for ARM builds in the previous step before promoting the rele
### 13. Check the Release ### 13. Check the Release
Your release should be available at <https://nodejs.org/dist/vx.y.z/> and <https://nodejs.org/dist/latest/>. 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 <https://nodejs.org/api/>. Check that the release catalog files are correct at <https://nodejs.org/dist/index.tab> and <https://nodejs.org/dist/index.json>. Your release should be available at `https://nodejs.org/dist/vx.y.z/` and <https://nodejs.org/dist/latest/>. 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 <https://nodejs.org/api/>. Check that the release catalog files are correct at <https://nodejs.org/dist/index.tab> and <https://nodejs.org/dist/index.json>.
### 14. Create a Blog Post ### 14. Create a Blog Post
@ -312,7 +312,7 @@ Refs: <full URL to your release proposal PR>
### 15. Announce ### 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 > v5.8.0 of @nodejs is out: https://nodejs.org/en/blog/release/v5.8.0/ … something here about notable changes