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 15 additions and 12 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.
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.