semantic-release 17.4.6 → 17.4.7

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (10) hide show
  1. package/README.md +1 -1
  2. package/docs/recipes/github-actions.md +3 -3
  3. package/docs/recipes/gitlab-ci.md +2 -2
  4. package/docs/recipes/jenkins-ci.md +5 -5
  5. package/docs/recipes/travis.md +3 -3
  6. package/docs/support/FAQ.md +4 -34
  7. package/docs/support/node-support-policy.md +1 -1
  8. package/docs/support/node-version.md +8 -8
  9. package/docs/usage/installation.md +1 -1
  10. package/package.json +3 -3
package/README.md CHANGED
@@ -97,7 +97,7 @@ In order to use **semantic-release** you need:
97
97
  - To host your code in a [Git repository](https://git-scm.com)
98
98
  - Use a Continuous Integration service that allows you to [securely set up credentials](docs/usage/ci-configuration.md#authentication)
99
99
  - 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
100
- - [Node.js](https://nodejs.org) version [10.18 or higher](docs/support/FAQ.md#why-does-semantic-release-require-node-version--1018) installed in your Continuous Integration environment
100
+ - [Node.js](https://nodejs.org) version [10.19 or higher](docs/support/FAQ.md#why-does-semantic-release-require-node-version--1019) installed in your Continuous Integration environment
101
101
 
102
102
  ## Documentation
103
103
 
package/docs/recipes/github-actions.md CHANGED
@@ -10,11 +10,11 @@ In this example a publish type [`NPM_TOKEN`](https://docs.npmjs.com/creating-and
10
10
 
11
11
  [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.
12
12
 
13
- **Note**: The publish pipeline must run on [Node version >= 10.18](../support/FAQ.md#why-does-semantic-release-require-node-version--1018).
13
+ **Note**: The publish pipeline must run on [Node version >= 10.19](../support/FAQ.md#why-does-semantic-release-require-node-version--1019).
14
14
 
15
15
  ### `.github/workflows/release.yml` configuration for Node projects
16
16
 
17
- The following is a minimal configuration for [`semantic-release`](https://github.com/semantic-release/semantic-release) with a build running on Node 12 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.
17
+ The following is a minimal configuration for [`semantic-release`](https://github.com/semantic-release/semantic-release) with a build running on Node 10.19 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.
18
18
 
19
19
  ```yaml
20
20
  name: Release
@@ -34,7 +34,7 @@ jobs:
34
34
  - name: Setup Node.js
35
35
  uses: actions/setup-node@v1
36
36
  with:
37
- node-version: 12
37
+ node-version: '10.19'
38
38
  - name: Install dependencies
39
39
  run: npm ci
40
40
  - name: Release
package/docs/recipes/gitlab-ci.md CHANGED
@@ -10,7 +10,7 @@ The [Authentication](../usage/ci-configuration.md#authentication) environment va
10
10
 
11
11
  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.
12
12
 
13
- **Note**: The publish pipeline must run a [Node >= 10.18 version](../support/FAQ.md#why-does-semantic-release-require-node-version--1018).
13
+ **Note**: The publish pipeline must run a [Node >= 10.19 version](../support/FAQ.md#why-does-semantic-release-require-node-version--1019).
14
14
 
15
15
  ### `.gitlab-ci.yml` configuration for Node projects
16
16
 
@@ -54,7 +54,7 @@ This example is a minimal configuration for **semantic-release** with a build ru
54
54
 
55
55
 
56
56
  ```yaml
57
- # The release pipeline will run only on the master branch a commit is triggered
57
+ # The release pipeline will run only on the master branch a commit is triggered
58
58
  stages:
59
59
  - release
60
60
 
package/docs/recipes/jenkins-ci.md CHANGED
@@ -10,7 +10,7 @@ Alternatively, the default `NPM_TOKEN` and `GH_TOKEN` can be easily [setup with
10
10
 
11
11
  ### `Jenkinsfile (Declarative Pipeline)` configuration for a Node.js job
12
12
 
13
- **Note**: The publish pipeline must run a [Node >= 10.18 version](../support/FAQ.md#why-does-semantic-release-require-node-version--1018).
13
+ **Note**: The publish pipeline must run a [Node >= 10.19 version](../support/FAQ.md#why-does-semantic-release-require-node-version--1019).
14
14
 
15
15
  This example is a minimal configuration for **semantic-release** with a build running Node 10.18. See [Jenkins documentation](https://www.jenkins.io/doc/) for additional configuration options.
16
16
 
@@ -19,7 +19,7 @@ The`semantic-release` execution command varies depending if you are using a [loc
19
19
  ```yaml
20
20
  // The release stage in the pipeline will run only if the test stage in the pipeline is successful
21
21
  pipeline {
22
- agent any
22
+ agent any
23
23
  environment {
24
24
  GH_TOKEN = credentials('some-id')
25
25
  }
@@ -35,14 +35,14 @@ pipeline {
35
35
  }
36
36
  stage('Release') {
37
37
  tools {
38
- nodejs "node 10.18"
38
+ nodejs "node 10.19"
39
39
  }
40
40
  steps {
41
41
  sh '''
42
42
  # Run optional required steps before releasing
43
43
  npx semantic-release
44
44
  '''
45
- }
45
+ }
46
46
  }
47
47
  }
48
48
  }
@@ -58,4 +58,4 @@ A `package.json` is required only for [local](../usage/installation.md#local-ins
58
58
  "semantic-release": "^15.0.0"
59
59
  }
60
60
  }
61
- ```
61
+ ```
package/docs/recipes/travis.md CHANGED
@@ -10,7 +10,7 @@ Alternatively, the default `NPM_TOKEN` and `GH_TOKEN` can be easily [setup with
10
10
 
11
11
  ### `.travis.yml` configuration for multiple Node.js jobs
12
12
 
13
- This example is a minimal configuration for **semantic-release** with a build running Node 6 and 8. See [Travis - Customizing the Build](https://docs.travis-ci.com/user/customizing-the-build) for additional configuration options.
13
+ This example is a minimal configuration for **semantic-release** with a build running Node 10 and 12. See [Travis - Customizing the Build](https://docs.travis-ci.com/user/customizing-the-build) for additional configuration options.
14
14
 
15
15
  This example creates a `release` [build stage](https://docs.travis-ci.com/user/build-stages) that [runs `semantic-release` only after all test jobs are successful](../usage/ci-configuration.md#run-semantic-release-only-after-all-tests-succeeded).
16
16
 
@@ -24,8 +24,8 @@ It's recommended to run the `semantic-release` command in the [Travis `deploy` s
24
24
  language: node_js
25
25
 
26
26
  node_js:
27
- - 8
28
- - 6
27
+ - 10
28
+ - 12
29
29
 
30
30
  jobs:
31
31
  include:
package/docs/support/FAQ.md CHANGED
@@ -38,44 +38,14 @@ If using npm hook scripts is not possible, and alternative solution is to [`@sem
38
38
 
39
39
  Yes with the [dry-run options](../usage/configuration.md#dryrun) which prints to the console the next version to be published and the release notes.
40
40
 
41
- ## Can I use semantic-release with Yarn?
42
-
43
- If you are using a [local](../usage/installation.md#local-installation) **semantic-release** installation and run multiple CI jobs with different versions, the `yarn install` command will fail on jobs running with Node < 8 as **semantic-release** requires [Node >= 10.18](#why-does-semantic-release-require-node-version--1018) and specifies it in its `package.json`s [`engines`](https://docs.npmjs.com/files/package.json#engines) key.
44
-
45
- The recommended solution is to use the [Yarn](https://yarnpkg.com) [--ignore-engines](https://yarnpkg.com/en/docs/cli/install#toc-yarn-install-ignore-engines) option to install the project dependencies on the CI environment, so Yarn will ignore the **semantic-release**'s `engines` key:
46
-
47
- ```bash
48
- $ yarn install --ignore-engines
49
- ```
50
-
51
- **Note**: Several CI services use Yarn by default if your repository contains a `yarn.lock` file. So you should override the install step to specify `yarn install --ignore-engines`.
52
-
53
- Alternatively you can use a [global](../usage/installation.md#global-installation) **semantic-release** installation and make sure to install and run the `semantic-release` command only in a CI jobs running with Node >= 10.18.
54
-
55
- If your CI environment provides [nvm](https://github.com/creationix/nvm) you can switch to Node 8 before installing and running the `semantic-release` command:
56
-
57
- ```bash
58
- $ nvm install 8 && yarn global add semantic-release && semantic-release
59
- ```
60
-
61
- See the [CI configuration recipes](../recipes/README.md#ci-configurations) for more details on specific CI environments.
62
-
63
- As `semantic-release` is recommended to be executed with [`npx`](https://www.npmjs.com/package/npx) an alternative is required for usage with Yarn. Even though it is possible to install npx with Yarn, it's not recommended. Yarn and npx would be using different cache locations.
64
-
65
- For [local installation](../usage/installation.md#local-installation) replace
66
- `npx semantic-release` with `yarn run semantic-release`.
67
-
68
- For [global installation](../usage/installation.md#global-installation) replace
69
- `npx semantic-release` with `yarn global add semantic-release && semantic-release`.
70
-
71
41
  ## Can I use semantic-release to publish non-JavaScript packages?
72
42
 
73
- Yes, **semantic-release** is a Node CLI application but it can be used to publish any type of packages.
43
+ Yes, **semantic-release** is a Node CLI application, but it can be used to publish any type of packages.
74
44
 
75
45
  To publish a non-Node package (without a `package.json`) you would need to:
76
46
  - Use a [global](../usage/installation.md#global-installation) **semantic-release** installation
77
47
  - Set **semantic-release** [options](../usage/configuration.md#options) via [CLI arguments or rc file](../usage/configuration.md#configuration)
78
- - Make sure your CI job executing the `semantic-release` command has access to [Node >= 10.18](#why-does-semantic-release-require-node-version--1018) to execute the `semantic-release` command
48
+ - Make sure your CI job executing the `semantic-release` command has access to [Node >= 10.19](#why-does-semantic-release-require-node-version--1019) to execute the `semantic-release` command
79
49
 
80
50
  See the [CI configuration recipes](../recipes/README.md#ci-configurations) for more details on specific CI environments.
81
51
 
@@ -234,9 +204,9 @@ See [“Introduction to SemVer” - Irina Gebauer](https://blog.greenkeeper.io/i
234
204
 
235
205
  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).
236
206
 
237
- ## Why does semantic-release require Node version >= 10.18?
207
+ ## Why does semantic-release require Node version >= 10.19?
238
208
 
239
- **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 10.18 or higher**.
209
+ **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 10.19 or higher**.
240
210
 
241
211
  See [Node version requirement](./node-version.md#node-version-requirement) for more details and solutions.
242
212
 
package/docs/support/node-support-policy.md CHANGED
@@ -1,6 +1,6 @@
1
1
  # Node Support Policy
2
2
 
3
- We only support [Long-Term Support](https://github.com/nodejs/Release) versions of Node starting with [Node 8.9.0 (LTS)](https://nodejs.org/en/blog/release/v8.9.0).
3
+ We only support [Long-Term Support](https://github.com/nodejs/Release) versions of Node starting with [Node 10.19 (LTS)](https://nodejs.org/en/blog/release/v10.19.0).
4
4
 
5
5
  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.
6
6
 
package/docs/support/node-version.md CHANGED
@@ -1,16 +1,16 @@
1
1
  # Node version requirement
2
2
 
3
- **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 10 or higher**.
3
+ **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 10.19 or higher**.
4
4
 
5
- **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 8 or higher.
5
+ **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 10.19 or higher.
6
6
 
7
7
  See our [Node Support Policy](node-support-policy.md) for our long-term promise regarding Node version support.
8
8
 
9
9
  ## Recommended solution
10
10
 
11
- ### Run at least one CI job with Node >= 10.18
11
+ ### Run at least one CI job with Node >= 10.19
12
12
 
13
- The recommended approach is to run the `semantic-release` command from a CI job running on Node 10.18 or higher. This can either be a job used by your project to test on Node >= 10.18 or a dedicated job for the release steps.
13
+ The recommended approach is to run the `semantic-release` command from a CI job running on Node 10.19 or higher. This can either be a job used by your project to test on Node >= 10.19 or a dedicated job for the release steps.
14
14
 
15
15
  See [CI configuration](../usage/ci-configuration.md) and [CI configuration recipes](../recipes/README.md#ci-configurations) for more details.
16
16
 
@@ -18,18 +18,18 @@ See [CI configuration](../usage/ci-configuration.md) and [CI configuration recip
18
18
 
19
19
  ### Use `npx`
20
20
 
21
- `npx` is included with npm >= 5.2 and can be used to download the latest [Node 8 package published on npm](https://www.npmjs.com/package/node). Use it to execute the `semantic-release` command.
21
+ `npx` is included with npm >= 5.2 and can be used to download the latest [Node 10 package published on npm](https://www.npmjs.com/package/node). Use it to execute the `semantic-release` command.
22
22
 
23
23
  ```bash
24
- $ npx -p node@8 -c "npx semantic-release"
24
+ $ npx -p node@10 -c "npx semantic-release"
25
25
  ```
26
26
 
27
27
  **Note:**: See [What is npx](./FAQ.md#what-is-npx) for more details.
28
28
 
29
29
  ### Use `nvm`
30
30
 
31
- If your CI environment provides [nvm](https://github.com/creationix/nvm) you can use it to switch to Node 8 before running the `semantic-release` command.
31
+ If your CI environment provides [nvm](https://github.com/creationix/nvm) you can use it to switch to Node 10.19 before running the `semantic-release` command.
32
32
 
33
33
  ```bash
34
- $ nvm install 8 && npx semantic-release
34
+ $ nvm install 10.19 && npx semantic-release
35
35
  ```
package/docs/usage/installation.md CHANGED
@@ -24,6 +24,6 @@ For other type of projects we recommend installing **semantic-release** directly
24
24
  $ npx semantic-release
25
25
  ```
26
26
 
27
- **Note**: For a global installation, it's recommended to specify the major **semantic-release** version to install (for example with with `npx semantic-release@15`). 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.
27
+ **Note**: For a global installation, it's recommended to specify the major **semantic-release** version to install (for example with with `npx semantic-release@17`). 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.
28
28
 
29
29
  **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.
package/package.json CHANGED
@@ -1,7 +1,7 @@
1
1
  {
2
2
  "name": "semantic-release",
3
3
  "description": "Automated semver compliant package publishing",
4
- "version": "17.4.6",
4
+ "version": "17.4.7",
5
5
  "author": "Stephan Bönnemann <stephan@boennemann.me> (http://boennemann.me)",
6
6
  "ava": {
7
7
  "files": [
@@ -56,7 +56,7 @@
56
56
  "delay": "5.0.0",
57
57
  "dockerode": "3.3.0",
58
58
  "file-url": "3.0.0",
59
- "fs-extra": "10.0.0",
59
+ "fs-extra": "9.1.0",
60
60
  "got": "11.8.2",
61
61
  "js-yaml": "4.1.0",
62
62
  "mockserver-client": "5.11.2",
@@ -70,7 +70,7 @@
70
70
  "xo": "0.29.1"
71
71
  },
72
72
  "engines": {
73
- "node": ">=10.18"
73
+ "node": ">=10.19"
74
74
  },
75
75
  "files": [
76
76
  "bin",