BREAKING CHANGE: If you run travis_after_all and travis-after-all at the same
time they'll keep waiting for each other until forever. You have to apply
this patch to your `.travis.yml`.
```diff
---
.travis.yml | 3 ---
1 file changed, 3 deletions(-)
diff --git a/.travis.yml b/.travis.yml
index a5fbddb..c76091b 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -14,9 +14,6 @@ before_install:
- npm i -g npm@^2.0.0
before_script:
- npm prune
-- curl -Lo travis_after_all.py https://git.io/vLSON
after_success:
-- python travis_after_all.py
-- export $(cat .to_export_back)
- npm run semantic-release
--
```
You can now map dist-tags onto "fallbackTags". E.g. if you want a
development channel like "next" and no version is currently published as "next"
semantic-release will fallback to "latest" to determine the new "next" version.
This is now the default for "next" -> "latest", but you can specify your own
mappings by adding "fallbackTags" to your `package.json`'s "release" field.
BREAKING CHANGE: In cases where you pushed a new commit with a "dist-tag"
configuration of "next" and no version was previously published as "next",
semanitc-release failed and did not publish a new version. It will now
automatically fall back to to "latest".
2015-08-22 21:36:11 +02:00
4 changed files with 37 additions and 14 deletions
Out of the box this is just about _commit-messages_, but you can do so much more.
@@ -31,7 +31,7 @@ Out of the box this is just about _commit-messages_, but you can do so much more
| **manual/before** | <pre><code><div>npm version major</div><div>git push origin master --tags</div><div>npm publish</div></code></pre> | You **manually decide** what the **next version** is. You have to remember what major, minor and patch means. You have to remember to push both commits and tags. You have to wait for the CI to pass. |
| **semantic-release/after** | <pre><code><div>git commit -m "fix: <message>"</div><div>git push</div></code></pre> | You **describe the changes** you’ve made. A new version is automatically published with the correct version number.
This removes the immediate connection between human emotions and version numbers, so strictly following the [SemVer](http://semver.org/) spec is not a problem anymore –and that’s ultimately `semantic-release`’s goal.
This removes the immediate connection between human emotions and version numbers, so strictly following the [SemVer](http://semver.org/) spec is not a problem anymore –and that’s ultimately `semantic-release`’s goal.
<table>
<tr>
@@ -96,7 +96,7 @@ _Note:_ The current release/tag implementation is tied to GitHub, but could be o
This module ships with the [AngularJS Commit Message Conventions](https://docs.google.com/document/d/1QrDFcIiPjSLDn3EL15IJygNPiHORgU1_OOAqWjiDU5Y/edit) and changelog generator, but you can [define your own](#plugins) style.
Each commit message consists of a **header**, a **body** and a **footer**. The header has a special
format that includes a **type**, a **scope** and a **subject**:
format that includes a **type**, a **scope** and a **subject** ([full explanation](https://github.com/ajoslin/conventional-changelog/blob/master/conventions/angular.md)):
```
<type>(<scope>): <subject>
@@ -106,7 +106,27 @@ format that includes a **type**, a **scope** and a **subject**:
You can simplify using this convention for yourself and contributors by using [commitizen](https://github.com/commitizen/cz-cli) and [validate-commit-msg](https://github.com/kentcdodds/validate-commit-msg).
### Patch Release
```
fix(pencil): stop graphite breaking when too much pressure applied
```
### ~~Minor~~ Fix Release
```
feat(pencil): add 'graphiteWidth' option
```
### ~~Major~~ Breaking Release
```
perf(pencil): remove graphiteWidth option
BREAKING CHANGE: The graphiteWidth option has been removed. The default graphite width of 10mm is always used for performance reason.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.