docs(node-version): consolidated and clarified the details about the required node version (#2170)

README.md

@@ -100,8 +100,8 @@ In order to use **semantic-release** you need:
 
 - To host your code in a [Git repository](https://git-scm.com)
 - Use a Continuous Integration service that allows you to [securely set up credentials](docs/usage/ci-configuration.md#authentication)
-- Git CLI version [2.7.1 or higher](docs/support/FAQ.md#why-does-semantic-release-require-git-version--271) installed in your Continuous Integration environment
+- A Git CLI version that meets [our version requirement](docs/support/git-version.md) installed in your Continuous Integration environment
-- [Node.js](https://nodejs.org) version [14.17 or higher](docs/support/FAQ.md#why-does-semantic-release-require-node-version--1417) installed in your Continuous Integration environment
+- A [Node.js](https://nodejs.org) version that meets [our version requirement](docs/support/node-version.md) installed in your Continuous Integration environment
 
 ## Documentation
 

docs/recipes/circleci-workflows.md

@@ -10,11 +10,14 @@ Alternatively, the default `NPM_TOKEN` and `GH_TOKEN` can be easily [setup with
 
 ### `.circleci/config.yml` configuration for multiple Node jobs
 
-This example is a minimal configuration for **semantic-release** with tests running against Node 16 and 14. See [CircleCI documentation](https://circleci.com/docs/2.0) for additional configuration options.
+This example is a minimal configuration for **semantic-release** with tests running against Node 16 and 14.
+See [CircleCI documentation](https://circleci.com/docs/2.0) for additional configuration options.
 
 In this example, the [`circleci/node`](https://circleci.com/developer/orbs/orb/circleci/node) orb is imported (Which makes some node operations easier), then a `release` job is defined which will run `semantic-release`.
 
-To run our `release` job, we have created a workflow named `test_and_release` which will run two jobs, `node/test`, which comes from the node orb and will test our application, and our release job. Here, we are actually making use of [matrix jobs](https://circleci.com/blog/circleci-matrix-jobs/) so that our single `node/test` job will actually be executed twice, once for Node version 16, and once for version 14. Finally, we call our release job with a `requires` parameter so that `release` will only run after `node/test` has successfully tested against v14 and v16.
+To run our `release` job, we have created a workflow named `test_and_release` which will run two jobs, `node/test`, which comes from the node orb and will test our application, and our release job.
+Here, we are actually making use of [matrix jobs](https://circleci.com/blog/circleci-matrix-jobs/) so that our single `node/test` job will actually be executed twice, once for Node version 16, and once for version 14.
+Finally, we call our release job with a `requires` parameter so that `release` will run against the latest LTS version of node, only after `node/test` has successfully tested against v14 and v16.
 
 ```yaml
 version: 2.1
@@ -25,6 +28,8 @@ jobs:
     executor: node/default
     steps:
       - checkout
+      - node/install
+          lts: true
       - node/install-packages # Install and automatically cache packages
       # Run optional required steps before releasing
       # - run: npm run build-script
@@ -44,15 +49,3 @@ workflows:
           requires:
             - node/test
 ```
-
-### `package.json` configuration for multiple Node jobs
-
-A `package.json` is required only for [local](../usage/installation.md#local-installation) **semantic-release** installation.
-
-```json
-{
-  "devDependencies": {
-    "semantic-release": "^18.0.0"
-  }
-}
-```

docs/recipes/github-actions.md

@@ -10,11 +10,11 @@ In this example a publish type [`NPM_TOKEN`](https://docs.npmjs.com/creating-and
 
 [GitHub Actions](https://github.com/features/actions) support [Workflows](https://help.github.com/en/articles/configuring-workflows), allowing to run tests on multiple Node versions and publish a release only when all test pass.
 
-**Note**: The publish pipeline must run on [Node version >= 14.17](../support/FAQ.md#why-does-semantic-release-require-node-version--1417).
+**Note**: The publish pipeline must run on a [Node version that meets our version requirement](../support/node-version.md).
 
 ### `.github/workflows/release.yml` configuration for Node projects
 
-The following is a minimal configuration for [`semantic-release`](https://github.com/semantic-release/semantic-release) with a build running on Node 14.17 when a new commit is pushed to a `master` branch.
+The following is a minimal configuration for [`semantic-release`](https://github.com/semantic-release/semantic-release) with a build running on the latest LTS version of Node when a new commit is pushed to a `master` branch.
 See [Configuring a Workflow](https://help.github.com/en/articles/configuring-a-workflow) for additional configuration options.
 
 ```yaml

docs/recipes/gitlab-ci.md

@@ -10,13 +10,13 @@ The [Authentication](../usage/ci-configuration.md#authentication) environment va
 
 GitLab CI supports [Pipelines](https://docs.gitlab.com/ee/ci/pipelines.html) allowing to test on multiple Node versions and publishing a release only when all test pass.
 
-**Note**: The publish pipeline must run a [Node >= 14.17 version](../support/FAQ.md#why-does-semantic-release-require-node-version--1417).
+**Note**: The publish pipeline must run a [Node version that meets our version requirement](../support/node-version.md).
 
 ### `.gitlab-ci.yml` configuration for Node projects
 
 This example is a minimal configuration for **semantic-release** with a build running Node 10 and 12. See [GitLab CI - Configuration of your jobs with .gitlab-ci.yml](https://docs.gitlab.com/ee/ci/yaml/README.html) for additional configuration options.
 
-**Note**: The`semantic-release` execution command varies depending if you are using a [local](../usage/installation.md#local-installation) or [global](../usage/installation.md#global-installation) **semantic-release** installation.
+**Note**: The`semantic-release` execution command varies depending on whether you are using a [local](../usage/installation.md#local-installation) or [global](../usage/installation.md#global-installation) **semantic-release** installation.
 
 ```yaml
 # The release pipeline will run only if all jobs in the test pipeline are successful

docs/recipes/jenkins-ci.md

@@ -10,11 +10,11 @@ Alternatively, the default `NPM_TOKEN` and `GH_TOKEN` can be easily [setup with
 
 ### `Jenkinsfile (Declarative Pipeline)` configuration for a Node.js job
 
-**Note**: The publish pipeline must run a [Node >= 14.17 version](../support/FAQ.md#why-does-semantic-release-require-node-version--1417).
+**Note**: The publish pipeline must run a Node version that [meets our requirement](../support/node-version.md).
 
-This example is a minimal configuration for **semantic-release** with a build running Node 14.17. See [Jenkins documentation](https://www.jenkins.io/doc/) for additional configuration options.
+This example is a minimal configuration for **semantic-release** with a build running a version of Node labelled as "node LTS".
-
+Since versions of Node are manually downloaded and labelled, we recommend keeping the version used for the release steps up-to-date with the latest LTS version.
-The`semantic-release` execution command varies depending if you are using a [local](../usage/installation.md#local-installation) or [global](../usage/installation.md#global-installation) **semantic-release** installation.
+See the [Jenkins documentation](https://www.jenkins.io/doc/) for additional configuration options.
 
 ```yaml
 // The release stage in the pipeline will run only if the test stage in the pipeline is successful
@@ -31,11 +31,11 @@ pipeline {
                 npm install
                 npm test
                 '''
-                }
+            }
         }
         stage('Release') {
             tools {
-            nodejs "node 14.17"
+                nodejs "node LTS"
             }
             steps {
                 sh '''
@@ -58,4 +58,4 @@ A `package.json` is required only for [local](../usage/installation.md#local-ins
     "semantic-release": "^18.0.0"
   }
 }
-```
+```

docs/support/FAQ.md

@@ -45,11 +45,11 @@ Yes, **semantic-release** is a Node CLI application, but it can be used to publi
 To publish a non-Node package (without a `package.json`) you would need to:
 - Use a [global](../usage/installation.md#global-installation) **semantic-release** installation
 - Set **semantic-release** [options](../usage/configuration.md#options) via [CLI arguments or rc file](../usage/configuration.md#configuration)
-- Make sure your CI job executing the `semantic-release` command has access to [Node >= 14.17](#why-does-semantic-release-require-node-version--1417) to execute the `semantic-release` command
+- Make sure your CI job executing the `semantic-release` command has access to a version of Node that [meets our version requirement](./node-version.md) to execute the `semantic-release` command
 
 See the [CI configuration recipes](../recipes/README.md#ci-configurations) for more details on specific CI environments.
 
-In addition you will need to configure the **semantic-release** [plugins](../usage/plugins.md#plugins) to disable the [`@semantic-release/npm`](https://github.com/semantic-release/npm) plugin which is used by default and use a plugin for your project type.
+In addition, you will need to configure the **semantic-release** [plugins](../usage/plugins.md#plugins) to disable the [`@semantic-release/npm`](https://github.com/semantic-release/npm) plugin which is used by default and use a plugin for your project type.
 
 If there is no specific plugin for your project type you can use the [`@semantic-release/exec`](https://github.com/semantic-release/exec) plugin to publish the release with a shell command.
 
@@ -200,19 +200,9 @@ See [“Introduction to SemVer” - Irina Gebauer](https://blog.greenkeeper.io/i
 
 ## Can I trust semantic-release with my releases?
 
-**semantic-release** has a full unit and integration test suite that tests `npm` publishes against the [npm-registry-couchapp](https://github.com/npm/npm-registry-couchapp).
+**semantic-release** has a full unit and integration test suite that tests `npm` publishes against the [verdaccio](https://www.npmjs.com/package/verdaccio).
 
-In addition the [verify conditions step](../../README.md#release-steps) verifies that all necessary conditions for proceeding with a release are met, and a new release will be performed [only if all your tests pass](../usage/ci-configuration.md#run-semantic-release-only-after-all-tests-succeeded).
+In addition, the [verify conditions step](../../README.md#release-steps) verifies that all necessary conditions for proceeding with a release are met, and a new release will be performed [only if all your tests pass](../usage/ci-configuration.md#run-semantic-release-only-after-all-tests-succeeded).
-
-## Why does semantic-release require Node version >= 14.17?
-
-**semantic-release** is written using the latest [ECMAScript 2017](https://www.ecma-international.org/publications/standards/Ecma-262.htm) features, without transpilation which **requires Node version 14.17 or higher**.
-
-See [Node version requirement](./node-version.md#node-version-requirement) for more details and solutions.
-
-## Why does semantic-release require Git version >= 2.7.1?
-
-**semantic-release** uses Git CLI commands to read information about the repository such as branches, commit history and tags. Certain commands and options (such as [the `--merged` option of the `git tag` command](https://git-scm.com/docs/git-tag/2.7.0#git-tag---no-mergedltcommitgt) or bug fixes related to `git ls-files`) used by **semantic-release** are only available in Git version 2.7.1 and higher.
 
 ## What is npx?
 

docs/support/git-version.md

@@ -0,0 +1,4 @@
+# Git version requirement
+
+**semantic-release** uses Git CLI commands to read information about the repository such as branches, commit history and tags.
+Certain commands and options (such as [the `--merged` option of the `git tag` command](https://git-scm.com/docs/git-tag/2.7.0#git-tag---no-mergedltcommitgt) or bug fixes related to `git ls-files`) used by **semantic-release** are only available in Git version 2.7.1 and higher.

docs/support/node-support-policy.md

@@ -1,13 +1,21 @@
 # Node Support Policy
 
-We only support [Long-Term Support](https://github.com/nodejs/Release) versions of Node starting with [Node 14.17.0 (LTS)](https://nodejs.org/en/blog/release/v14.17.0).
+We will always support at least the latest [Long-Term Support](https://github.com/nodejs/Release) version of Node, but provide no promise of support for older versions.
+The supported range will always be defined in the `engines.node` property of the `package.json` of our packages.
 
 We specifically limit our support to LTS versions of Node, not because this package won't work on other versions, but because we have a limited amount of time, and supporting LTS offers the greatest return on that investment.
 
-It's possible this package will work correctly on newer versions of Node. It may even be possible to use this package on older versions of Node, though that's more unlikely as we'll make every effort to take advantage of features available in the oldest LTS version we support.
+It's possible this package will work correctly on newer versions of Node.
+It may even be possible to use this package on older versions of Node, though that's more unlikely as we'll make every effort to take advantage of features available in the oldest LTS version we support.
 
-As each Node LTS version reaches its end-of-life we will remove that version from the node engines property of our package's package.json file. Removing a Node version is considered a breaking change and will entail the publishing of a new major version of this package. We will not accept any requests to support an end-of-life version of Node. Any merge requests or issues supporting an end-of-life version of Node will be closed.
+As new Node LTS versions become available we may remove previous versions from the `engines.node` property of our package's `package.json` file.
+Removing a Node version is considered a breaking change and will entail the publishing of a new major version of this package.
+We will not accept any requests to support an end-of-life version of Node.
+Any merge requests or issues supporting an end-of-life version of Node will be closed.
 
-We will accept code that allows this package to run on newer, non-LTS, versions of Node. Furthermore, we will attempt to ensure our own changes work on the latest version of Node. To help in that commitment, our continuous integration setup runs against all LTS versions of Node in addition the most recent Node release; called current.
+We will accept code that allows this package to run on newer, non-LTS, versions of Node.
+Furthermore, we will attempt to ensure our own changes work on the latest version of Node.
+To help in that commitment, our continuous integration setup runs against all LTS versions of Node in addition the most recent Node release; called current.
 
-JavaScript package managers should allow you to install this package with any version of Node, with, at most, a warning if your version of Node does not fall within the range specified by our node engines property. If you encounter issues installing this package, please report the issue to your package manager.
+JavaScript package managers should allow you to install this package with any version of Node, with, at most, a warning if your version of Node does not fall within the range specified by our node engines property.
+If you encounter issues installing this package, please report the issue to your package manager.

docs/support/node-version.md

@@ -2,36 +2,37 @@
 
 **semantic-release** is written using the latest [ECMAScript 2017](https://www.ecma-international.org/publications/standards/Ecma-262.htm) features, without transpilation which requires **requires Node version 14.17 or higher**.
 
-**semantic-release** is meant to be used in a CI environment as a development support tool, not as a production dependency. Therefore, the only constraint is to run the `semantic-release` in a CI environment providing Node 14.17 or higher.
+**semantic-release** is meant to be used in a CI environment as a development support tool, not as a production dependency.
+Therefore, the only constraint is to run the `semantic-release` in a CI environment providing version of Node that meets our version requirement.
 
 See our [Node Support Policy](node-support-policy.md) for our long-term promise regarding Node version support.
 
 ## Recommended solution
 
-### Run at least one CI job with Node >= 14.17
+### Run at least one CI job with a version of Node that meets our version requirement
 
-The recommended approach is to run the `semantic-release` command from a CI job running on Node 14.17 or higher.
+The recommended approach is to run the `semantic-release` command from a CI job running on the latest available LTS version of node.
-This can either be a job used by your project to test on Node >= 14.17 or a dedicated job for the release steps.
+This can either be a job used by your project to test on the latest Node LTS version or a dedicated job for the release steps.
 
 See [CI configuration](../usage/ci-configuration.md) and [CI configuration recipes](../recipes/README.md#ci-configurations) for more details.
 
 ## Alternative solutions
 
-### Use `npx`
+### Use `npx` to execute in the latest LTS version of Node
 
-`npx` is included with npm >= 5.2 and can be used to download the latest [Node 14 package published on npm](https://www.npmjs.com/package/node).
+`npx` is included with npm >= 5.2 and can be used to download the latest [Node LTS package published on npm](https://www.npmjs.com/package/node).
 Use it to execute the `semantic-release` command.
 
 ```bash
-$ npx -p node@14 -c "npx semantic-release"
+$ npx -p node@lts -c "npx semantic-release"
 ```
 
-**Note:**: See [What is npx](./FAQ.md#what-is-npx) for more details.
+**Note**: See [What is npx](./FAQ.md#what-is-npx) for more details.
 
 ### Use `nvm`
 
-If your CI environment provides [nvm](https://github.com/creationix/nvm) you can use it to switch to Node 14.17 before running the `semantic-release` command.
+If your CI environment provides [nvm](https://github.com/creationix/nvm) you can use it to switch to the latest LTS version of Node before running the `semantic-release` command.
 
 ```bash
-$ nvm install 14.17 && npx semantic-release
+$ nvm install 'lts/*' && npx semantic-release
 ```

docs/usage/installation.md

@@ -25,6 +25,8 @@ $ npx semantic-release
 ```
 
 **Note**: For a global installation, it's recommended to specify the major **semantic-release** version to install (for example with with `npx semantic-release@18`).
-This way your build will not automatically use the next major **semantic-release** release that could possibly break your build. You will have to upgrade manually when a new major version is released.
+This way your build will not automatically use the next major **semantic-release** release that could possibly break your build.
+You will have to upgrade manually when a new major version is released.
 
-**Note**: `npx` is a tool bundled with `npm@>=5.2.0`. It is used to conveniently install the semantic-release binary and to execute it. See [What is npx](../support/FAQ.md#what-is-npx) for more details.
+**Note**: `npx` is a tool bundled with `npm@>=5.2.0`. It is used to conveniently install the semantic-release binary and to execute it.
+See [What is npx](../support/FAQ.md#what-is-npx) for more details.