semantic-release 20.0.2 → 20.0.3
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.
|
@@ -29,11 +29,11 @@ jobs:
|
|
|
29
29
|
runs-on: ubuntu-latest
|
|
30
30
|
steps:
|
|
31
31
|
- name: Checkout
|
|
32
|
-
uses: actions/checkout@
|
|
32
|
+
uses: actions/checkout@v3
|
|
33
33
|
with:
|
|
34
34
|
fetch-depth: 0
|
|
35
35
|
- name: Setup Node.js
|
|
36
|
-
uses: actions/setup-node@
|
|
36
|
+
uses: actions/setup-node@v3
|
|
37
37
|
with:
|
|
38
38
|
node-version: "lts/*"
|
|
39
39
|
- name: Install dependencies
|
|
@@ -62,7 +62,7 @@ The Git history of the repository is now:
|
|
|
62
62
|
|
|
63
63
|
We now decide to work on another future major release, in parallel of the beta one, which will also be composed of multiple features, some of them being breaking changes.
|
|
64
64
|
|
|
65
|
-
To implement that workflow we can create the branch `alpha` from the branch `beta` and commit our first feature there. When pushing that commit, **semantic-release** will publish the pre-release version `3.0.0-alpha.1` on the dist-tag `@alpha`. That allow us to run integration tests by installing our module with `npm install example-module@alpha`. Other users installing with `npm install example-module` will still receive the version `1.0.
|
|
65
|
+
To implement that workflow we can create the branch `alpha` from the branch `beta` and commit our first feature there. When pushing that commit, **semantic-release** will publish the pre-release version `3.0.0-alpha.1` on the dist-tag `@alpha`. That allow us to run integration tests by installing our module with `npm install example-module@alpha`. Other users installing with `npm install example-module` will still receive the version `1.0.1`.
|
|
66
66
|
|
|
67
67
|
The Git history of the repository is now:
|
|
68
68
|
|
|
@@ -24,7 +24,7 @@ See [CI configuration](../usage/ci-configuration.md) and [CI configuration recip
|
|
|
24
24
|
Use it to execute the `semantic-release` command.
|
|
25
25
|
|
|
26
26
|
```bash
|
|
27
|
-
$ npx -p node@lts -c "npx semantic-release"
|
|
27
|
+
$ npx -p node@v18-lts -c "npx semantic-release"
|
|
28
28
|
```
|
|
29
29
|
|
|
30
30
|
**Note**: See [What is npx](./FAQ.md#what-is-npx) for more details.
|
|
@@ -12,7 +12,7 @@ See [Release workflow recipes](../recipes/release-workflow/README.md#release-wor
|
|
|
12
12
|
The release workflow is configured via the [branches option](./configuration.md#branches) which accepts a single or an array of branch definitions.
|
|
13
13
|
Each branch can be defined either as a string, a [glob](https://github.com/micromatch/micromatch#matching-features) or an object. For string and glob definitions each [property](#branches-properties) will be defaulted.
|
|
14
14
|
|
|
15
|
-
A branch can defined as one of three types:
|
|
15
|
+
A branch can be defined as one of three types:
|
|
16
16
|
|
|
17
17
|
- [release](#release-branches): to make releases on top of the last version released
|
|
18
18
|
- [maintenance](#maintenance-branches): to make releases on top of an old release
|
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": "20.0.
|
|
4
|
+
"version": "20.0.3",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"author": "Stephan Bönnemann <stephan@boennemann.me> (http://boennemann.me)",
|
|
7
7
|
"ava": {
|
|
@@ -66,8 +66,8 @@
|
|
|
66
66
|
"fs-extra": "^11.0.0",
|
|
67
67
|
"got": "^12.5.0",
|
|
68
68
|
"js-yaml": "4.1.0",
|
|
69
|
-
"mockserver-client": "5.
|
|
70
|
-
"nock": "13.
|
|
69
|
+
"mockserver-client": "5.15.0",
|
|
70
|
+
"nock": "13.3.0",
|
|
71
71
|
"p-retry": "^5.1.1",
|
|
72
72
|
"prettier": "^2.7.1",
|
|
73
73
|
"sinon": "15.0.1",
|