- Remove the `getLastRelease` plugin type
- Retrieve the last release based on Git tags
- Create the next release Git tag before calling the `publish` plugins
BREAKING CHANGE: Remove the `getLastRelease` plugin type
The `getLastRelease` plugins will not be called anymore.
BREAKING CHANGE: Git repository authentication is now mandatory
The Git authentication is now mandatory and must be set via `GH_TOKEN`, `GITHUB_TOKEN`, `GL_TOKEN`, `GITLAB_TOKEN` or `GIT_CREDENTIALS` as described in [CI configuration](https://github.com/semantic-release/semantic-release/blob/caribou/docs/usage/ci-configuration.md#authentication).
**Refactor and clarify the documentation in `README.md`**
- Add Highlights
- Add a Table of contents
- Clarify the way semantic-release works
- Clarify relationship with the CI environments
- Describe local install for Node projects (with a `package.json`) and global install for non-JavaScript projects
- Explain CI general configuration (environment variables and a run after all jobs are successful)
- Clarify configuration (via config file or CLI arguments)
- Clarify plugin roles and configuration
- Add doc for shareable configuration
- Add recipes
- Add resources (Videos, articles, tutorials)
- Add a Support section
- Add a Team section
**Add the following FAQs**
- How can I use a npm build script that requires the `package.json`’s version ?
- Can I use Semantic-release with Yarn?
- Can I use Semantic-release to publish non-JavaScript packages?
- Can I use Semantic-release with any CI service?
- Can I use Semantic-release with any GitLab?
- Can I use Semantic-release with any Git hosted environment?
- Can I skip the release to the npm registry?
- Can I use .npmrc options?
- How can I set the access level of the published npm package?
- Can I use Semantic-release to publish a package on Artifactory?
- Can I set the initial release version of my package to 0.0.1?
- Why does semantic-release require Node version >= 8?
**Clarify Nove 8 requirement and solutions**
- Add Node version requirement explanation and solutions
- [X] Display a link to the documentation when running on Node < 8 version
**Add recipes**
- Travis
- GitLab CI
- Travis with build stages - To be done in #573
- CircleCI workflows - To be done in #573
The marked dependency defined in package-lock.json has a known moderate severity security vulnerability in version range < 0.3.9 and should be updated.
- Remove `@semantic-release/condition-travis` from the default plugins
- Verify the current branch in the core
- Verify the build is not triggered by a PR in the core
- Run in dry-run mode if not triggered on CI
- Dry-run mode runs the `verifyConditions` plugins, allowing to detect configuration error locally
- Return without error when no version has to be released due to no changes
- Return without error if the build is triggered from a PR
- Return without error if the current branch is not the configured branch
- CLI return with exit code 1 if there is a `semanticReleaseError`, allowing to fail builds in case of config error, missing token etc...
BREAKING CHANGE: `semantic-release` doesn't make sure it runs only on one Travis job anymore.
The CI configuration has to be done such that `semantic-release`
- runs only once per build
- runs only after all tests are successful on every jobs of the build
- runs on Node >=8
This can easily be done with [travis-deploy-once](https://github.com/semantic-release/travis-deploy-once).
Migration Guide
Modify your `.travis.yml` to use `travis-deploy-once`.
Replace:
```yaml
after_success:
- npm run semantic-release
```
by:
Replace
```yaml
after_success:
- npm install -g travis-deploy-once@4
- travis-deploy-once "npm run semantic-release"
```
Adds the options `extends`, which can be defined via configuration file or CLI arguments to a single path or an array of paths of shareable configuration.
A shareable configuration is a file or a module that can be loaded with `require`.
Options is defined by merging in the following order of priority:
- CLI/API
- Configuration file
- Shareable configuration (from right to left)
Options set in a shareable configuration can be unset by setting it to `null` or `undefined` in the main configuration file. If a default value applies to this property it will be used.
Add a _Node Support Policy_ section to the project's `README.md` file
to indicate what this project, and its core team, are promising in terms
of Node runtime support.
Establishing a support policy provides reassurance to the community that
they can expect a level of functionality from `semantic-release`, while
providing guidance to the core maintainers, and everyone else that
contributes, the level of support they should espire to.
Closes#485
`npm` is called through `semantic-release` and in the integration test to make some assertion.
By isolating the the environment variables passed to `semantic-release` it's easier to avoid a mistake that would pass the test environment that contains is own auth variables.
