summaryrefslogtreecommitdiff
path: root/doc/guides
diff options
context:
space:
mode:
authorNick Schonning <nschonni@gmail.com>2019-09-01 02:18:32 -0400
committerRich Trott <rtrott@gmail.com>2019-09-03 20:55:39 -0700
commita3307eac0e6fb276274e4e9bbaab1aa4433e795f (patch)
tree8f28047c28dc917181c068c768afc1bb870bed6b /doc/guides
parent27a57d3a3449e4d6b9c07ef3bb56c4b0b43c133d (diff)
downloadandroid-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.md52
-rw-r--r--doc/guides/diagnostic-tooling-support-tiers.md34
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