diff --git a/README.md b/README.md
index 0484c091..4b4b73c9 100644
--- a/README.md
+++ b/README.md
@@ -1,10 +1,6 @@
# :package::rocket: semantic-release
-**Fully automated package publishing**
-
-> **Trust us, this will change your workflow for the better.**
-
-> – [egghead.io](https://egghead.io/lessons/javascript-how-to-write-a-javascript-library-automating-releases-with-semantic-release)
+Fully automated version management and package publishing.
[](https://gitter.im/semantic-release/semantic-release?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge)
[](https://travis-ci.org/semantic-release/semantic-release)
@@ -15,123 +11,137 @@
[](https://www.npmjs.com/package/semantic-release)
[](https://www.npmjs.com/package/semantic-release)
-Out of the box this is just about _commit-messages_, but you can do so much more.
+semantic-release automates the whole package release workflow including: determining the next version number, generating the release notes and publishing the package. This removes the immediate connection between human emotions and version numbers, strictly following the [Semantic Versioning](http://semver.org) specification.
-* **Detect breaking changes** using the test suite of your last release: [cracks](https://github.com/semantic-release/cracks)
-* Detect breaking changes using your dependents’ test suites: [Help out! Implement the **dont-break** plugin](https://github.com/semantic-release/semantic-release/issues/65)
-* Detect breaking changes diffing your JSDoc interface: [Help out! Implement the **india** plugin](https://github.com/semantic-release/semantic-release/issues/66)
-* Abort releases with **insufficient test coverage**: [Help out! Implement the **istanbul** plugin](https://github.com/semantic-release/semantic-release/issues/68)
-* Abort releases with **vulnerable dependencies** in the tree: [Help out! Implement the **nsp** plugin](https://github.com/semantic-release/semantic-release/issues/67)
-* Everything you can imagine: [Build Plugins!](https://github.com/semantic-release/semantic-release#plugins)
+> Trust us, this will change your workflow for the better. – [egghead.io](https://egghead.io/lessons/javascript-how-to-write-a-javascript-library-automating-releases-with-semantic-release)
- | Commands | Comment
---- | --- | ---
-| **manual/before** | npm version major
git push origin master --tags
npm publish
git commit -m "fix: <message>"
git push
-
-
- “How to Write a JavaScript Library - Automating Releases with semantic-release” – egghead.io
-
-
-
-
-
-
-
-
- A free egghead.io tutorial series on how to write an open source library featuring semantic-release.
-
-
-
-
- “We fail to follow SemVer – and why it needn’t matter”
-
-
- “semantic-release Q&A with Kent C. Dodds”
-
-
-
-
-
-
-
-
-
-
- This talk gives you a complete introduction to the underlying concepts of this module. 38:30
-
-
- A “Hangouts on Air” conversation with hands on questions and answers about how to use semantic-release. 53:52
-
-
-
+## Table of Contents
+
+- [How does it work?](#how-does-it-work)
+- [Installation and Usage](#installation-and-usage)
+- [Plugins](#plugins)
+- [Shareable configurations](#shareable-configurations)
+- [Recipes](#recipes)
+- [Frequently Asked Questions](#frequently-asked-questions)
+- [Resources](#resources)
+- [Support](#support)
+- [Badge](#badge)
+- [Node Support Policy](#node-support-policy)
+- [Team](#team)
## How does it work?
-Instead of writing [meaningless commit messages](http://whatthecommit.com/), we can take our time to think about the changes in the codebase and write them down. Following formalized conventions it is then possible to generate a helpful changelog and to derive the next semantic version number from them.
+### Commit message format
-When `semantic-release` is set up it will do that after every successful continuous integration build of your master branch (or any other branch you specify) and publish the new version for you. This way no human is directly involved in the release process and your releases are guaranteed to be [unromantic and unsentimental](http://sentimentalversioning.org/).
+semantic-release uses the commit messages to determine the type of changes in the codebase. Following formalized conventions for commit messages, semantic-release automatically determines the next [semantic version](https://semver.org) number, generates a changelog and publish the release.
-If you fear the loss of control over timing and marketing implications of software releases you should know that `semantic-release` supports [release channels](https://github.com/npm/npm/issues/2718) using `npm`’s [dist-tags](https://docs.npmjs.com/cli/dist-tag). This way you can keep control over what your users end up using by default, you can decide when to promote an automatically released version to the stable channel, and you can choose which versions to write blogposts and tweets about. You can use the same mechanism to [support older versions of your software](https://gist.github.com/boennemann/54042374e49c7ade8910), for example with important security fixes.
+By default semantic-release uses [Angular Commit Message Conventions](https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines). The commit message format that can changed with the [`preset` or `config` options](#options) of the [@semantic-release/commit-analyzer](https://github.com/semantic-release/commit-analyzer#options) and [@semantic-release/release-notes-generator](https://github.com/semantic-release/release-notes-generator#options) plugins.
-When pushing new commits with `git push` a CI build is triggered. After running the tests the command `semantic-release` will execute the following tasks in series:
+Tools such as [commitizen](https://github.com/commitizen/cz-cli), [commitlint](https://github.com/marionebl/commitlint) or [semantic-git-commit-cli](https://github.com/JPeer264/node-semantic-git-commit-cli) can be used to help contributor and enforce valid commits message.
-| Step | Description |
-| ------------------ | ------------------------------------------------------------------------------------------- |
-| Verify Conditions | Run the [verifyConditions](#verifyconditions) plugin |
-| Get last release | Obtain last release with the [getLastRelease](#getlastrelease) plugin |
-| Analyze commits | Determine the type of release to do with the [analyzeCommits](#analyzecommits) plugin |
-| Verify release | Call the [verifyRelease](#verifyrelease) plugin |
-| Generate notes | Generate release notes with plugin [generateNotes](#generatenotes) |
-| Publish | Call the [publish](#publish) plugin |
+Here is an example of the release type that will be done based on a commit messages:
-## Default Commit Message Format
+| Commit message | Release type |
+|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------|
+| `fix(pencil): stop graphite breaking when too much pressure applied` | Patch Release |
+| `feat(pencil): add 'graphiteWidth' option` | ~~Minor~~ Feature Release |
+| `perf(pencil): remove graphiteWidth option`():
-
-
-
-
+### Triggering a release
+
+When pushing new commits to the release branch (i.e. `master`) with `git push` or by merging a pull request or merging from another branch, a CI build is triggered and runs the `semantic-release` command to make a release if there is relevant codebase changes since the last release.
+
+By default a release will be done for each push to the release branch that contains relevant code changes. If you need more control over the timing of releases you have a couple of options:
+- Publish releases on a distribution channel (for example npm’s [dist-tags](https://docs.npmjs.com/cli/dist-tag)). This way you can keep control over what your users end up using by default, and you can decide when to make an automatically released version available to the stable channel, and promote it.
+- Develop on a `dev` branch and merge it to the release branch (i.e. `master`) once you are ready to publish. semantic-release will run only on pushes to the release branch.
+
+### Release steps
+
+After running the tests the command `semantic-release` will execute the following steps:
+
+| Step | Description |
+|-------------------|--------------------------------------------------------------------------------------------------------------------------------------------------|
+| Verify Conditions | Verify all the conditions to proceed with the release with the [verify conditions plugins](#verifyconditions-plugin). |
+| Get last release | Obtain last release with the [get last release plugin](#getlastrelease-plugin). |
+| Analyze commits | Determine the type of release to do with the [analyze commits plugin](#analyzecommits-plugin) based on the commits added since the last release. |
+| Verify release | Verify the release conformity with the [verify release plugins](#verifyrelease-plugin). |
+| Generate notes | Generate release notes with the [generate notes plugin](#generatenotes-plugin) for the commits added since the last release. |
+| Publish | Publish the release with the [publish plugins](#publish-plugin). |
+
+## Installation and Usage
+
+### Local installation
+
+For [Node modules projects](https://docs.npmjs.com/getting-started/creating-node-modules) we recommend to install semantic-release locally and to run the `semantic-release` command with a [npm script](https://docs.npmjs.com/misc/scripts):
+
+```bash
+$ npm install --save-dev semantic-release
```
-You can simplify using this convention for yourself and contributors by using [commitizen](https://github.com/commitizen/cz-cli) and [commitlint](https://github.com/marionebl/commitlint) or [semantic-git-commit-cli](https://github.com/JPeer264/node-semantic-git-commit-cli).
+In your `package.json`:
-### Patch Release
-
-```
-fix(pencil): stop graphite breaking when too much pressure applied
+```json
+"scripts": {
+ "semantic-release": "semantic-release"
+}
```
-### ~~Minor~~ Feature Release
+Then in the CI environment:
-```
-feat(pencil): add 'graphiteWidth' option
+```bash
+$ npm run semantic-release
```
-### ~~Major~~ Breaking Release
+### Global installation
-```
-perf(pencil): remove graphiteWidth option
+For other type of projects we recommend to install semantic-release globally directly in the CI environment:
-BREAKING CHANGE: The graphiteWidth option has been removed. The default graphite width of 10mm is always used for performance reasons.
+```bash
+$ npm install -g semantic-release
+$ semantic-release
```
-## Setup
+### CI configuration
-[](https://nodei.co/npm/semantic-release/)
+#### Run `semantic-release` only after all tests succeeded
+
+The `semantic-release` command must be executed only after all the tests in the CI build pass. If the build runs multiple jobs (for example to test on multiple Operating Systems or Node versions) the CI has to be configured to guarantee that the `semantic-release` command is executed only after all jobs are successful. This can be achieved with [Travis Build Stages](https://docs.travis-ci.com/user/build-stages), [CircleCI Workflows](https://circleci.com/docs/2.0/workflows), [Codeship Deployment Pipelines](https://documentation.codeship.com/basic/builds-and-configuration/deployment-pipelines), [GitLab Pipelines](https://docs.gitlab.com/ee/ci/pipelines.html#introduction-to-pipelines-and-jobs), [Wercker Workflows](http://devcenter.wercker.com/docs/workflows), [GoCD Pipelines](https://docs.gocd.org/current/introduction/concepts_in_go.html#pipeline) or specific tools like [`travis-deploy-once`](https://github.com/semantic-release/travis-deploy-once).
+
+See [CI configuration recipes](docs/recipes/README.md#ci-configurations) for more details.
+
+#### Authentication
+
+Most semantic-release [plugins](#plugins) require to set up authentication in order to publish to your package manager's registry or to access your project's Git hosted service. The authentication token/credentials have to be made available in the CI serice via environment variables.
+
+See each plugin documentation for the environment variable to set up.
+
+The default [npm](https://github.com/semantic-release/npm#environment-variables) and [github](https://github.com/semantic-release/github#environment-variables) plugins require the following environment variables:
+
+| Variable | Description |
+|-------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| `NPM_TOKEN` | npm token created via [npm token create](https://docs.npmjs.com/getting-started/working_with_tokens#how-to-create-new-tokens). GH_TOKEN= npm run semantic-release --no-ci
+```
+
+However this is not the recommended approach, as running unit and integration tests on an independent machine before publishing software is a crucial part of the release workflow.
+
+### Can I use semantic-release with GitLab?
+
+Yes, with the [`@semantic-release/gitlab-config`](https://github.com/semantic-release/gitlab-config) shareable configuration.
+
+See the [GitLab CI recipes](docs/recipes/gitlab-ci.md#using-semantic-release-with-gitlab-ci) for the CI configuration.
+
+### Can I use semantic-release with any Git hosted environment?
+
+By default semantic-release uses the [`@semantic-release/github`](https://github.com/semantic-release/github) plugin to publish a [GitHub release](https://help.github.com/articles/about-releases). For other Git hosted environment the [`@semantic-release/git`](https://github.com/semantic-release/git) and [`@semantic-release/changelog`](https://github.com/semantic-release/changelog) plugins can be used via [plugins configuration](#plugins-configuration).
+
+See the [`@semantic-release/git`](https://github.com/semantic-release/git#semantic-releasegit) [`@semantic-release/changelog`](https://github.com/semantic-release/changelog#semantic-releasechangelog) plugins documentation for more details.
+
+### Can I skip the release to the npm registry?
+
+Yes, the publishing to the npm registry can be disabled with the [`npmPublish`](https://github.com/semantic-release/npm#options) option of the [`@semantic-release/npm`](https://github.com/semantic-release/npm) plugin. In addition the [`tarballDir`](https://github.com/semantic-release/npm#options) option allow to generate the package tarball in order to publish it to your repository with the [`@semantic-release/git`](https://github.com/semantic-release/git) or to a [GitHub release](https://help.github.com/articles/about-releases) with the [`@semantic-release/github`](https://github.com/semantic-release/github) plugin.
+
+See the [`@semantic-release/npm`](https://github.com/semantic-release/npm#semantic-releasenpm) plugin documentation for more details.
+
+### Can I use `.npmrc` options?
+
+Yes, all the [npm configuration options](https://docs.npmjs.com/misc/config) are supported via the [`.npmrc`](https://docs.npmjs.com/files/npmrc) file at the root of your repository.
+
+See the [`@semantic-release/npm`](https://github.com/semantic-release/npm#npm-configuration) plugin documentation for more details.
+
+### How can I set the access level of the published npm package?
+
+The [npm `access` option](https://docs.npmjs.com/misc/config#access) can be set in the [`.npmrc`](https://docs.npmjs.com/files/npmrc) file at the root of your repository:
+
+```rc
+access=public
+```
+
+Or with the `publishConfig.access` key in your project's `package.json`:
+
+```json
+{
+ "publishConfig": {
+ "access": "public"
+ }
+}
+```
+
+### Can I use semantic-release to publish a package on Artifactory?
+
+Any npm compatible registry is supported with the [`@semantic-release/npm`](https://github.com/semantic-release/npm) plugin. For Artifactory versions prior to 5.4, the legacy authentication has to be used (with `NPM_USERNAME`, `NPM_PASSWORD` and `NPM_EMAIL` [environment variables](https://github.com/semantic-release/npm#environment-variables)).
+
+See [npm registry authentication](https://github.com/semantic-release/npm#npm-registry-authentication) for more details.
+
+See [Artifactory - npm Registry](https://www.jfrog.com/confluence/display/RTF/Npm+Registry#NpmRegistry-AuthenticatingthenpmClient) documentation for Artifactiry configuration.
### Can I manually trigger the release of a specific version?
-You can trigger a release by pushing to your GitHub repository. You deliberately cannot trigger a _specific_ version release, because this is the whole point of `semantic-release`. Start your packages with `1.0.0` and semver on.
+You can trigger a release by pushing to your Git repository. You deliberately cannot trigger a *specific* version release, because this is the whole point of semantic-release.
-### Is it _really_ a good idea to release on every push?
+### Is it *really* a good idea to release on every push?
-It is indeed a great idea because it _forces_ you to follow best practices. If you don’t feel comfortable making every passing feature or fix on your master branch addressable via `npm` you might not treat your master right. Have a look at [branch workflows](https://guides.github.com/introduction/flow/index.html). If you still think you should have control over the exact point in time of your release, e.g. because you are following a release schedule, you can release only on the `production`/`deploy`/`release` branch and push your code there in certain intervals, or better yet use [dist-tags](https://docs.npmjs.com/cli/dist-tag).
+It is indeed a great idea because it *forces* you to follow best practices. If you don’t feel comfortable releasing every feature or fix on your `master` you might not treat your `master` branch as intended.
-### Why should I trust `semantic-release` with my releases?
+From [Understanding the GitHub Flow](https://guides.github.com/introduction/flow/index.html):
-`semantic-release` has a full unit- and integration-test-suite that tests _actual_ `npm` publishes against the [npm-registry-couchapp](https://github.com/npm/npm-registry-couchapp/). A new version won’t get published if it doesn’t pass on all these engines.
+> Branching is a core concept in Git, and the entire GitHub Flow is based upon it. There's only one rule: anything in the master branch is always deployable.
-### Why does `semantic-release` require node version >= 8
+If you need more control over the timing of releases, see [Triggering a release](#triggering-a-release) for different options.
-Being able to write code for just the most recent node versions greatly simplifies development. More language features are available, no transpilation is required, less test builds are to be run, awaited and debugged.
+### Can I set the initial release version of my package to `0.0.1`?
-For a special purpose tool like `semantic-release`, that's only meant to be used in controlled CI environments, we think it's okay to have such a high version requirement. As `semantic-release` handles package publishing we expect almost every project to have at least one build job running node 8 already – and that's all it takes. Even if that's not that case `semantic-release` can still be executed with the help of [npx](https://www.npmjs.com/package/npx) (`npx -p node@8 npm run semantic-release`).
+This is not supported by semantic-release as it's not considered a good practice, mostly because [Semantic Versioning](https://semver.org) rules applies differently to major version zero.
-Please see our [Node Support Policy](#node-support-policy) for our long-term promise for supporting Node.
+In early development phase when your package is not ready for production yet we recommend to publish releases on a distribution channel (for example npm’s [dist-tags](https://docs.npmjs.com/cli/dist-tag)) or to develop on a `dev` branch and merge it to `master` periodically. See [Triggering a release](#triggering-a-release) for more details on those solutions.
+
+See [“Introduction to SemVer” - Irina Gebauer](https://blog.greenkeeper.io/introduction-to-semver-d272990c44f2) for more details on [Semantic Versioning](https://semver.org) and the recommendation to start at version `1.0.0`.
+
+### 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).
+
+In addition the [verify conditions step](#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](#run-semantic-release-only-after-all-tests-succeeded).
+
+### Why does semantic-release require Node version >= 8?
+
+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 8 or higher**.
+
+See [Node version requirement](docs/node-version.md#node-version-requirement) for more details and solutions.
+
+## Resources
+
+### Videos
+
+- ["Introducing Reliable Dependency and Release Management for npm Packages" - Gregor Martynus](https://www.youtube.com/watch?v=R2RJWLcfzwc)
+- ["Kill all humans" - Jan Lehnardt](https://www.youtube.com/watch?v=ZXyx_1kN1L8&t=2s)
+- [Publishing JavaScript Packages" - JavaScript Air](https://javascriptair.com/episodes/2016-07-20)
+- ["Managing Dependencies like a boss 😎" - JavaScript Air](https://javascriptair.com/episodes/2016-08-17)
+- ["Dependency Hell Just Froze Over" - Stephan Bönnemann](https://www.youtube.com/watch?v=PA139CERNbc)
+- [“semantic-release Q&A with Kent C. Dodds”](https://www.youtube.com/watch?v=g6y3DnhkjrI)
+- [“We fail to follow SemVer – and why it needn’t matter” - Stephan Bönnemann](https://www.youtube.com/watch?v=tc2UgG5L7WM)
+
+### Articles
+
+- [“Introduction to SemVer” - Irina Gebauer](https://blog.greenkeeper.io/introduction-to-semver-d272990c44f2)
+
+### Tutorials
+
+- [“How to Write a JavaScript Library - Automating Releases with semantic-release” – egghead.io](https://egghead.io/lessons/javascript-automating-releases-with-semantic-release)
+
+## Support
+
+- [Stack Overflow](https://stackoverflow.com/questions/tagged/semantic-release)
+- [Gitter chat](https://gitter.im/semantic-release/semantic-release)
+- [Twitter](https://twitter.com/SemanticRelease)
## Badge
-Use this in one of your projects? Include one of these badges in your README.md to let people know that your package is published using `semantic-release`.
+Let people know that your package is published using semantic-release by including this badge in your readme.
[](https://github.com/semantic-release/semantic-release)
@@ -303,21 +610,9 @@ Use this in one of your projects? Include one of these badges in your README.md
[](https://github.com/semantic-release/semantic-release)
```
-[](https://github.com/semantic-release/semantic-release)
-
-```md
-[](https://github.com/semantic-release/semantic-release)
-```
-
-[](https://github.com/semantic-release/semantic-release)
-
-```md
-[](https://github.com/semantic-release/semantic-release)
-```
-
## Node Support Policy
-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/).
+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).
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.
@@ -329,9 +624,10 @@ We will accept code that allows this package to run on newer, non-LTS, versions
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.
-## License
+## Team
-MIT License
-2015 © Stephan Bönnemann and [contributors](https://github.com/semantic-release/semantic-release/graphs/contributors)
+| [](https://github.com/boennemann) | [](https://github.com/relekang) | [](https://github.com/jo) | [](https://github.com/gr2m) | [](https://github.com/finnp) | [](https://github.com/pvdlg) | [](https://github.com/christophwitzko) |
+|---------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------|
+| [Stephan Bönnemann](https://github.com/boennemann) | [Rolf Erik Lekang](https://github.com/relekang) | [Johannes Jörg Schmidt](https://github.com/jo) | [Gregor Martynus](https://github.com/gr2m) | [Finn Pauls](https://github.com/finnp) | [Pierre Vanduynslager](https://github.com/pvdlg) | [Christoph Witzko](https://github.com/christophwitzko) |
[](https://twitter.com/trodrigues/status/509301317467373571)
diff --git a/bin/semantic-release.js b/bin/semantic-release.js
index 647b87b3..8e6f606e 100755
--- a/bin/semantic-release.js
+++ b/bin/semantic-release.js
@@ -3,22 +3,16 @@
// Bad news: We have to write plain ES5 in this file
// Good news: It's the only file of the entire project
-// eslint-disable-next-line no-var
+/* eslint-disable no-var */
+
var semver = require('semver');
+var pkg = require('../package.json');
-if (semver.lt(process.version, '8.0.0')) {
+if (!semver.satisfies(process.version, pkg.engines.node)) {
console.error(
- `semantic-release: node version >= 8 is required. Found ${process.version}.
+ `[semantic-release]: node version ${pkg.engines.node} is required. Found ${process.version}.
-If there is another job running on node version >= 8, it will be picked as
-the build leader and you can safely ignore this message.
-
-If you don't have node 8 in your build matrix you can use "npx" to restore
-compatibility with minimal overhead:
-
-$ npx -p node@8 npm run semantic-release
-
-npx is bundled with npm >= 5.4, or available via npm. More info: npm.im/npx`
+See https://github.com/semantic-release/semantic-release/blob/caribou/docs/node-version.md for more details and solutions.`
);
process.exit(1);
}
diff --git a/docs/README.md b/docs/README.md
new file mode 100644
index 00000000..01bb6068
--- /dev/null
+++ b/docs/README.md
@@ -0,0 +1,7 @@
+# semantic-release documentation
+
+- [Plugins](plugins.md#semantic-release-plugins) - List of semantic-release plugins
+- [Shareable configurations](shareable-configurations.md#semantic-release-shareable-configurations) - List of semantic-release shareable configs
+- [Developer Guide](developer-guide/README.md#semantic-release-developer-guide) - The essentials of writing a semantic-release plugin or shareable config
+- [Recipes](recipes/README.md#semantic-release-recipes) - Community written recipes for common semantic-release use-cases
+- [Troubleshooting](troubleshooting.md#troubleshooting-semantic-release) - Community written troubleshooting guide to help with common semantic-release issues
diff --git a/docs/developer-guide/README.md b/docs/developer-guide/README.md
new file mode 100644
index 00000000..e795865b
--- /dev/null
+++ b/docs/developer-guide/README.md
@@ -0,0 +1 @@
+# semantic-release Developer Guide
diff --git a/docs/developer-guide/plugin.md b/docs/developer-guide/plugin.md
new file mode 100644
index 00000000..c3ff79ed
--- /dev/null
+++ b/docs/developer-guide/plugin.md
@@ -0,0 +1 @@
+# semantic-release plugin development
diff --git a/docs/developer-guide/shareable-configuration.md b/docs/developer-guide/shareable-configuration.md
new file mode 100644
index 00000000..6aa0db8c
--- /dev/null
+++ b/docs/developer-guide/shareable-configuration.md
@@ -0,0 +1 @@
+# semantic-release shareable config development
diff --git a/docs/node-version.md b/docs/node-version.md
new file mode 100644
index 00000000..0de46bc4
--- /dev/null
+++ b/docs/node-version.md
@@ -0,0 +1,52 @@
+# Node version requirement
+
+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 8 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 8 or higher.
+
+See our [Node Support Policy](../README.md#node-support-policy) for our long-term promise regarding Node version support.
+
+## Recommended solution
+
+### Run at least one CI job with Node >= 8
+
+The recommended approach is to run the `semantic-release` command from a CI job running on Node 8 or higher. This can either be a job used by your project to test on Node 8 or a dedicated job for the release steps.
+
+See [CI configuration](../README.md#ci-configuration) and [CI configuration recipes](recipes/README.md#ci-configurations) for more details.
+
+## Alternative solutions
+
+### Use `npx`
+
+[`npx`](https://github.com/zkat/npx) is a CLI to execute npm binaries. It is bundled with [npm](https://www.npmjs.com/package/npm) >= 5.4, or can be installed via `npm install -g npx`.
+
+`npx` can be used to download the [Node 8 package published on npm](https://www.npmjs.com/package/node) and use it to execute the `semantic-release` command.
+
+If you are using a [local](../README.md#local-installation) semantic-release installation:
+
+```bash
+$ npm install -g npx && npx -p node@8 -c "npm run semantic-release"
+```
+
+If you are using a [global](../README.md#global-installation) semantic-release installation:
+
+```bash
+# For global semantic-release install
+$ npm install -g semantic-release npx && npx -p node@8 -c "semantic-release"
+```
+
+### Use `nvm`
+
+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.
+
+If you are using a [local](../README.md#local-installation) semantic-release installation:
+
+```bash
+$ nvm install 8 && npm run semantic-release
+```
+
+If you are using a [global](../README.md#global-installation) semantic-release installation:
+
+```bash
+$ nvm install 8 && npm install -g semantic-release && semantic-release
+```
diff --git a/docs/plugins.md b/docs/plugins.md
new file mode 100644
index 00000000..e76efa1c
--- /dev/null
+++ b/docs/plugins.md
@@ -0,0 +1,37 @@
+# semantic-release plugins
+
+## Default plugins
+
+ - [@semantic-release/github](https://github.com/semantic-release/github)
+ - [verifyConditions](https://github.com/semantic-release/github#verifyconditions): Verify the presence and the validity of the GitHub authentication and release configuration
+ - [publish](https://github.com/semantic-release/github#publish): Publish a [GitHub release](https://help.github.com/articles/about-releases)
+
+ - [@semantic-release/npm](https://github.com/semantic-release/npm)
+ - [verifyConditions](https://github.com/semantic-release/npm#verifyconditions): Verify the presence and the validity of the npm authentication and release configuration
+ - [getLastRelease](https://github.com/semantic-release/npm#getlastrelease): Determine the last release of the package on the npm registry
+ - [publish](https://github.com/semantic-release/npm#publish): Publish the package on the npm registry
+
+## Official plugins
+
+ - [@semantic-release/gitlab](https://github.com/semantic-release/gitlab)
+ - [verifyConditions](https://github.com/semantic-release/gitlab#verifyconditions): Verify the presence and the validity of the GitLab authentication and release configuration
+ - [publish](https://github.com/semantic-release/gitlab#publish): Publish a [GitLab release](https://docs.gitlab.com/ce/workflow/releases.html)
+
+ - [@semantic-release/git](https://github.com/semantic-release/git)
+ - [verifyConditions](https://github.com/semantic-release/git#verifyconditions): Verify the presence and the validity of the Git authentication and release configuration
+ - [getLastRelease](https://github.com/semantic-release/git#getlastrelease): Determine the last release via Git tags on the repository
+ - [publish](https://github.com/semantic-release/git#publish): Push a release commit and tag, including configurable files
+
+ - [@semantic-release/changelog](https://github.com/semantic-release/changelog)
+ - [verifyConditions](https://github.com/semantic-release/changelog#verifyconditions): Verify the presence and the validity of the configuration
+ - [publish](https://github.com/semantic-release/changelog#publish): Create or update the changelog file in the local project repository
+
+ - [@semantic-release/exec](https://github.com/semantic-release/exec)
+ - [verifyConditions](https://github.com/semantic-release/exec#verifyconditions): Execute a shell command to verify if the release should happen
+ - [getLastRelease](https://github.com/semantic-release/exec#getlastrelease): Execute a shell command to determine the last release
+ - [analyzeCommits](https://github.com/semantic-release/exec#analyzecommits): Execute a shell command to determine the type of release
+ - [verifyRelease](https://github.com/semantic-release/exec#verifyrelease): Execute a shell command to verifying a release that was determined before and is about to be published.
+ - [generateNotes](https://github.com/semantic-release/exec#analyzecommits): Execute a shell command to generate the release note
+ - [publish](https://github.com/semantic-release/exec#publish): Execute a shell command to publish the release.
+
+## Community plugins
diff --git a/docs/recipes/README.md b/docs/recipes/README.md
new file mode 100644
index 00000000..e64de03d
--- /dev/null
+++ b/docs/recipes/README.md
@@ -0,0 +1,9 @@
+# semantic-release recipes
+
+## CI configurations
+- [CircleCI 2.0 workflows](circleci-workflows.md)
+- [Travis CI](travis.md)
+- [Travis CI with build stages](travis-build-stages.md)
+- [GitLab CI](gitlab-ci.md)
+
+## Package managers and languages
diff --git a/docs/recipes/circleci-workflows.md b/docs/recipes/circleci-workflows.md
new file mode 100644
index 00000000..de5eb6d3
--- /dev/null
+++ b/docs/recipes/circleci-workflows.md
@@ -0,0 +1 @@
+# CircleCI 2.0 workflows
diff --git a/docs/recipes/gitlab-ci.md b/docs/recipes/gitlab-ci.md
new file mode 100644
index 00000000..0d99f1c9
--- /dev/null
+++ b/docs/recipes/gitlab-ci.md
@@ -0,0 +1,71 @@
+# Using semantic-release with [GitLab CI](https://about.gitlab.com/features/gitlab-ci-cd)
+
+## Environment variables
+
+The [Authentication](../../README.md#authentication) environment variables can be configured with [Secret variables](https://docs.gitlab.com/ce/ci/variables/README.html#secret-variables).
+
+## Node project configuration
+
+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 >= 8 version](../../README.md#why-does-semantic-release-require-node-version--8).
+
+### `.gitlab-ci.yml` configuration for Node projects
+
+This example is a minimal configuration for semantic-release with a build running Node 4, 6 and 8 on Linux. 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](../../README.md#local-installation) or [global](../../README.md#global-installation) semantic-release installation.
+
+```yaml
+# The release pipeline will run only if all jobs in the test pipeline are successful
+stages:
+ - test
+ - release
+
+before_script:
+ - npm install
+
+node:4:
+ image: node:4
+ stage: test
+ script:
+ - npm test
+
+node:6:
+ image: node:6
+ stage: test
+ script:
+ - npm test
+
+node:8:
+ image: node:8
+ stage: test
+ script:
+ - npm test
+
+publish:
+ image: node:8
+ stage: release
+ script:
+ # Only for a local semantic-release installation
+ - npm run semantic-release
+
+ # Only for a global semantic-release installation
+ - npm install semantic-release
+ - semantic-release
+```
+
+### `package.json` configuration
+
+A `package.json` is required only for [local semantic-release installations](../../README.md#local-installation).
+
+```json
+{
+ "devDependencies": {
+ "semantic-release": "^12.0.0"
+ },
+ "scripts": {
+ "semantic-release": "semantic-release"
+ }
+}
+```
diff --git a/docs/recipes/travis-build-stages.md b/docs/recipes/travis-build-stages.md
new file mode 100644
index 00000000..679ff75e
--- /dev/null
+++ b/docs/recipes/travis-build-stages.md
@@ -0,0 +1 @@
+# Using semantic-release with [Travis CI build stages](https://docs.travis-ci.com/user/build-stages)
diff --git a/docs/recipes/travis.md b/docs/recipes/travis.md
new file mode 100644
index 00000000..695f0cb0
--- /dev/null
+++ b/docs/recipes/travis.md
@@ -0,0 +1,151 @@
+# Using semantic-release with [Travis CI](https://travis-ci.org)
+
+## Environment variables
+
+The [Authentication](../../README.md#authentication) environment variables can be configured in [Travis Repository Settings](https://docs.travis-ci.com/user/environment-variables/#defining-variables-in-repository-Settings) or with the [travis env set CLI](https://github.com/travis-ci/travis.rb#env).
+
+Alternatively, the default `NPM_TOKEN` and `GH_TOKEN` can be easily [setup with semantic-release-cli](../../README.md#automatic-setup-with-semantic-release-cli).
+
+## Single Node job configuration
+
+For projects that require to be tested only with a single [Node version](https://docs.travis-ci.com/user/getting-started/#Selecting-a-different-programming-language) on [one Operating System](https://docs.travis-ci.com/user/getting-started/#Selecting-infrastructure-(optional)).
+
+**Note**: [Node 8 is the minimal version required](../../README.md#why-does-semantic-release-require-node-version--8).
+
+### `.travis.yml` configuration for single Node job
+
+This example is a minimal configuration for semantic-release with a build running Node 8 on Linux. See [Travis - Customizing the Build](https://docs.travis-ci.com/user/customizing-the-build) for additional configuration options.
+
+It's recommended to run the `semantic-release` command in the [Travis `script` step](https://docs.travis-ci.com/user/customizing-the-build/#The-Build-Lifecycle) so if an error happen the build will fail and Travis will send a notification.
+
+**Note**: The`semantic-release` execution command varies depending if you are using a [local](../../README.md#local-installation) or [global](../../README.md#global-installation) semantic-release installation.
+
+```yaml
+language: node_js
+
+node_js: 8
+
+script:
+ # Run tests
+ - npm run test
+
+ # Only for a local semantic-release installation
+ - npm run semantic-release
+
+ # Only for a global semantic-release installation
+ - npm install -g semantic-release
+ - semantic-release
+```
+
+### `package.json` configuration for single Node job
+
+A `package.json` is required only for [local semantic-release installations](../../README.md#local-installation).
+
+```json
+{
+ "devDependencies": {
+ "semantic-release": "^11.0.0"
+ },
+ "scripts": {
+ "semantic-release": "semantic-release"
+ }
+}
+```
+
+## Multiple Node jobs configuration
+
+For projects that require to be tested with multiple [Node versions](https://docs.travis-ci.com/user/languages/javascript-with-nodejs/#Specifying-Node.js-versions) and/or on multiple [Operating Systems](https://docs.travis-ci.com/user/multi-os).
+
+**Note**: At least one job must run a [Node >= 8 version](../../README.md#why-does-semantic-release-require-node-version--8).
+
+### `.travis.yml` configuration for multiple Node jobs
+
+This example is a minimal configuration for semantic-release with a build running Node 4, 6 and 8 on Linux and OSX. See [Travis - Customizing the Build](https://docs.travis-ci.com/user/customizing-the-build) for additional configuration options.
+
+This example uses [`travis-deploy-once`](https://github.com/semantic-release/travis-deploy-once) in order to command [Run `semantic-release` only after all tests succeeded](../../README.md#run-semantic-release-only-after-all-tests-succeeded). Alternatively you can use [Travis CI Build Stages recipe](travis-build-stages.md).
+
+It's recommended to run the `semantic-release` command in the [Travis `script` step](https://docs.travis-ci.com/user/customizing-the-build/#The-Build-Lifecycle) so if an error happen the build will fail and Travis will send a notification.
+
+**Note**: The`semantic-release` execution command varies depending if you are using a [local](../../README.md#local-installation) or [global](../../README.md#global-installation) semantic-release installation.
+
+```yaml
+language: node_js
+
+node_js:
+ - 8
+ - 6
+ - 4
+
+os:
+ - linux
+ - osx
+
+script:
+ # Run tests
+ - npm run test
+
+ # Only for a local semantic-release installation
+ - npm run travis-deploy-once "npm run semantic-release"
+
+ # Only for a global semantic-release installation
+ - npm install -g travis-deploy-once semantic-release
+ - travis-deploy-once "semantic-release"
+```
+
+**Note**: See the `travis-deploy-once` [`pro`](https://github.com/semantic-release/travis-deploy-once#-p---pro) and [`travis-url`](https://github.com/semantic-release/travis-deploy-once#-u---travis-url) options for using with [Travis Pro](https://docs.travis-ci.com/user/travis-pro) and [Travis Enterprise](https://enterprise.travis-ci.com).
+
+### `package.json` configuration for multiple Node jobs
+
+A `package.json` is required only for [local semantic-release installations](../../README.md#local-installation).
+
+```json
+{
+ "devDependencies": {
+ "semantic-release": "^12.0.0",
+ "travis-deploy-once": "^4.0.0"
+ },
+ "scripts": {
+ "semantic-release": "semantic-release",
+ "travis-deploy-once": "travis-deploy-once"
+ }
+}
+```
+
+## Non-JavaScript projects configuration
+
+For projects that require to be tested with one or multiple version of a Non-JavaScript [language](https://docs.travis-ci.com/user/languages), optionally on multiple [Operating Systems](https://docs.travis-ci.com/user/multi-os).
+
+This recipe cover the Travis specifics only. See [Non JavaScript projects recipe](../../README.md#can-i-use-semantic-release-to-publish-non-javascript-packages) for more information on the semantic-release configuration.
+
+### `.travis.yml` configuration for non-JavaScript projects
+
+This example is a minimal configuration for semantic-release with a build running [Go 1.6 and 1.7](https://docs.travis-ci.com/user/languages/go) on Linux and OSX. See [Travis - Customizing the Build](https://docs.travis-ci.com/user/customizing-the-build) for additional configuration options.
+
+This example uses [`travis-deploy-once`](https://github.com/semantic-release/travis-deploy-once) in order to [run `semantic-release` only after all tests succeeded](../../README.md#run-semantic-release-only-after-all-tests-succeeded). Alternatively you can use [Travis CI Build Stages recipe](travis-build-stages.md).
+
+It's recommended to run the `semantic-release` command in the [Travis `script` step](https://docs.travis-ci.com/user/customizing-the-build/#The-Build-Lifecycle) so if an error happen the build will fail and Travis will send a notification.
+
+```yaml
+language: go
+
+go:
+ - 1.6
+ - 1.7
+
+os:
+ - linux
+ - osx
+
+script:
+ # Run tests
+ - go test -v ./...
+
+ # Use nvm to install and use the Node LTS version (nvm is installed on Travis images)
+ - nvm install lts/*
+ # Install travis-deploy-once and semantic-release
+ - npm install -g travis-deploy-once semantic-release
+ # Run semantic-release only on job, after all other are successful
+ - travis-deploy-once "semantic-release"
+```
+
+**Note**: See the `travis-deploy-once` [`pro`](https://github.com/semantic-release/travis-deploy-once#-p---pro) and [`travis-url`](https://github.com/semantic-release/travis-deploy-once#-u---travis-url) options for using with [Travis Pro](https://docs.travis-ci.com/user/travis-pro) and [Travis Enterprise](https://enterprise.travis-ci.com).
diff --git a/docs/shareable-configurations.md b/docs/shareable-configurations.md
new file mode 100644
index 00000000..2f4d60c9
--- /dev/null
+++ b/docs/shareable-configurations.md
@@ -0,0 +1,7 @@
+# semantic-release shareable configurations
+
+## Official configurations
+- [@semantic-release/apm-config](https://github.com/semantic-release/apm-config) - :atom: semantic-release shareable config for releasing atom packages
+- [@semantic-release/gitlab-config](https://github.com/semantic-release/gitlab-config) - :fox_face: semantic-release shareable config for GitLab
+
+## Community configurations
diff --git a/TROUBLESHOOTING.md b/docs/troubleshooting.md
similarity index 100%
rename from TROUBLESHOOTING.md
rename to docs/troubleshooting.md
diff --git a/media/semantic-release-cli.png b/media/semantic-release-cli.png
new file mode 100644
index 00000000..103eff3a
Binary files /dev/null and b/media/semantic-release-cli.png differ
diff --git a/package.json b/package.json
index 6fac4dc6..46143ea2 100644
--- a/package.json
+++ b/package.json
@@ -14,6 +14,10 @@
"path": "cz-conventional-changelog"
}
},
+ "contributors": [
+ "Gregor Martynus (https://twitter.com/gr2m)",
+ "Pierre Vanduynslager (https://twitter.com/@pvdlg_)"
+ ],
"dependencies": {
"@semantic-release/commit-analyzer": "^5.0.0",
"@semantic-release/error": "^2.1.0",
@@ -60,11 +64,11 @@
"xo": "^0.18.2"
},
"engines": {
- "node": ">=4",
- "npm": ">=2"
+ "node": ">=8"
},
"files": [
"bin",
+ "docs",
"lib",
"index.js",
"cli.js"
- 
- 
-