diff options
author | Nick Schonning <nschonni@gmail.com> | 2019-09-01 02:18:32 -0400 |
---|---|---|
committer | Rich Trott <rtrott@gmail.com> | 2019-09-03 20:55:39 -0700 |
commit | a3307eac0e6fb276274e4e9bbaab1aa4433e795f (patch) | |
tree | 8f28047c28dc917181c068c768afc1bb870bed6b /doc/guides | |
parent | 27a57d3a3449e4d6b9c07ef3bb56c4b0b43c133d (diff) | |
download | android-node-v8-a3307eac0e6fb276274e4e9bbaab1aa4433e795f.tar.gz android-node-v8-a3307eac0e6fb276274e4e9bbaab1aa4433e795f.tar.bz2 android-node-v8-a3307eac0e6fb276274e4e9bbaab1aa4433e795f.zip |
doc: use consistent indenting for unordered list items
Address Markdownlint MD007 rule.
Default suggestion is 2 space indenting for unordered list items.
PR-URL: https://github.com/nodejs/node/pull/29390
Reviewed-By: David Carlier <devnexen@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Diffstat (limited to 'doc/guides')
-rw-r--r-- | doc/guides/adding-new-napi-api.md | 52 | ||||
-rw-r--r-- | doc/guides/diagnostic-tooling-support-tiers.md | 34 |
2 files changed, 43 insertions, 43 deletions
diff --git a/doc/guides/adding-new-napi-api.md b/doc/guides/adding-new-napi-api.md index aad0e6ba7a..dc8d9dda23 100644 --- a/doc/guides/adding-new-napi-api.md +++ b/doc/guides/adding-new-napi-api.md @@ -6,16 +6,16 @@ a set of principles and guidelines to keep in mind while adding a new N-API API. * A new API **must** adhere to N-API API shape and spirit. - * **Must** be a C API. - * **Must** not throw exceptions. - * **Must** return `napi_status`. - * **Should** consume `napi_env`. - * **Must** operate only on primitive data types, pointers to primitive - datatypes or opaque handles. - * **Must** be a necessary API and not a nice to have. Convenience APIs - belong in node-addon-api. - * **Must** not change the signature of an existing N-API API or break - ABI compatibility with other versions of Node.js. + * **Must** be a C API. + * **Must** not throw exceptions. + * **Must** return `napi_status`. + * **Should** consume `napi_env`. + * **Must** operate only on primitive data types, pointers to primitive + datatypes or opaque handles. + * **Must** be a necessary API and not a nice to have. Convenience APIs + belong in node-addon-api. + * **Must** not change the signature of an existing N-API API or break + ABI compatibility with other versions of Node.js. * New API **should** be agnostic towards the underlying JavaScript VM. * New API PRs **must** have a corresponding documentation update. * New API PRs **must** be tagged as **n-api**. @@ -31,19 +31,19 @@ N-API API. * A new API **must** be considered experimental for at least one minor version release of Node.js before it can be considered for promotion out of experimental. - * Experimental APIs **must** be documented as such. - * Experimental APIs **must** require an explicit compile-time flag - (`#define`) to be set to opt-in. - * Experimental APIs **must** be considered for backport. - * Experimental status exit criteria **must** involve at least the - following: - * A new PR **must** be opened in `nodejs/node` to remove experimental - status. This PR **must** be tagged as **n-api** and **semver-minor**. - * Exiting an API from experimental **must** be signed off by the team. - * If a backport is merited, an API **must** have a down-level - implementation. - * The API **should** be used by a published real-world module. Use of - the API by a real-world published module will contribute favorably - to the decision to take an API out of experimental status. - * The API **must** be implemented in a Node.js implementation with an - alternate VM. + * Experimental APIs **must** be documented as such. + * Experimental APIs **must** require an explicit compile-time flag + (`#define`) to be set to opt-in. + * Experimental APIs **must** be considered for backport. + * Experimental status exit criteria **must** involve at least the + following: + * A new PR **must** be opened in `nodejs/node` to remove experimental + status. This PR **must** be tagged as **n-api** and **semver-minor**. + * Exiting an API from experimental **must** be signed off by the team. + * If a backport is merited, an API **must** have a down-level + implementation. + * The API **should** be used by a published real-world module. Use of + the API by a real-world published module will contribute favorably + to the decision to take an API out of experimental status. + * The API **must** be implemented in a Node.js implementation with an + alternate VM. diff --git a/doc/guides/diagnostic-tooling-support-tiers.md b/doc/guides/diagnostic-tooling-support-tiers.md index 1368cdd666..62bca48e1b 100644 --- a/doc/guides/diagnostic-tooling-support-tiers.md +++ b/doc/guides/diagnostic-tooling-support-tiers.md @@ -18,16 +18,16 @@ the following tiers. early warning of potential issues. No commit to the current and LTS release branches should break this tool/API if the next major release is within 1 month. In addition: - * The maintainers of the tool must remain responsive when there - are problems; - * The tool must be actively used by the ecosystem; - * The tool must be heavily depended on; - * The tool must have a guide or other documentation in the Node.js GitHub - organization or website; - * The tool must be working on all supported platforms; - * The tool must only be using APIs exposed by Nodejs as opposed to - its dependencies; and - * The tool must be open source. + * The maintainers of the tool must remain responsive when there + are problems; + * The tool must be actively used by the ecosystem; + * The tool must be heavily depended on; + * The tool must have a guide or other documentation in the Node.js GitHub + organization or website; + * The tool must be working on all supported platforms; + * The tool must only be using APIs exposed by Nodejs as opposed to + its dependencies; and + * The tool must be open source. * Tier 2 - Must be working(CI tests passing) for all LTS releases. An LTS release will not be shipped if the test @@ -35,13 +35,13 @@ the following tiers. in this tier it must have a good test suite and that test suite and a job must exist in the Node.js CI so that it can be run as part of the release process. In addition: - * The maintainers of the tool must remain responsive when - there are problems; - * The tool must be actively used by the ecosystem; - * The tool must be heavily depended on; - * The tool must have a guide or other documentation in the Node.js GitHub - organization or website; - * The tool must be open source. + * The maintainers of the tool must remain responsive when + there are problems; + * The tool must be actively used by the ecosystem; + * The tool must be heavily depended on; + * The tool must have a guide or other documentation in the Node.js GitHub + organization or website; + * The tool must be open source. * Tier 3 - If possible its test suite will be run at least nightly in the Node.js CI and issues opened for |