BREAKING CHANGE: Committing or creating files in the `publish` plugin hook is not supported anymore and now must be done in the `prepare` hook
Plugins with a `publish` hook that makes a commit or create a file that can be committed must use the `prepare` hook.
Even the user set Git credentials via environment variable, use the configured URL (with authentication) if it works.
This allow users to push tags and commits via ssh while still using the GitHub/GitLab API.
BREAKING CHANGE: `success` and `fail` hooks are now enabled by default
In order to disable the `@semantic-release/github` plugin for the `success` and `fail` hook, the corresponding options have to be set to `false` in the **semantic-release** configuration:
```json
{
"release": {
"success": false,
"fail": false
}
}
```
Users who do not use the `@semantic-release/github` plugin, should disable it in the `success` and `fail` by setting the corresponding options to `false` or to alternative plugin providing `success` and `fail` hooks.
- Replace `commander.js` with `yargs`
- Add CLI unit tests
- Add a `--version` option
- Improve `--help` output
- Remove `commander.js` related workaround
- Allow to set list option with arg repetition or space separated list
- Maintain the list options defined as comma separated list
- Allow `publish` plugins to return an `Object` with information related to the releases
- Add the `success` plugin hook, called when all `publish` are successful, receiving a list of release
- Add the `fail` plugin hook, called when an error happens at any point, receiving a list of errors
- Add detailed message for each error
- 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
- 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.
