fix: revert undeclared breaking change

docs(README): list plugins and more talks
fix(condition-travis): remove need for python script travis_after_all
2015-08-23 22:34:10 +02:00 · 2015-08-23 22:26:35 +02:00 · 2015-08-23 00:57:37 +02:00 · 2015-08-22 23:59:25 +02:00 · 2015-08-22 23:33:36 +02:00 · 2015-08-22 21:48:16 +02:00
3 changed files with 2 additions and 11 deletions
@@ -26,7 +26,7 @@ Out of the box this is just about _commit-messages_, but you can do so much more
 | **manual** | <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** | <pre><code><div>git commit -m "fix: &lt;message&gt;"</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>
@@ -22,7 +22,7 @@
  },
  "dependencies": {
    "@semantic-release/commit-analyzer": "^2.0.0",
-    "@semantic-release/condition-travis": "^4.1.0",
+    "@semantic-release/condition-travis": "^4.1.2",
    "@semantic-release/error": "^1.0.0",
    "@semantic-release/last-release-npm": "^1.2.1",
    "@semantic-release/release-notes-generator": "^2.0.0",
@@ -66,12 +66,6 @@
  ],
  "license": "MIT",
  "main": "dist/index.js",
-  "publishConfig": {
-    "tag": "next"
-  },
-  "release": {
-    "branch": "next"
-  },
  "repository": {
    "type": "git",
    "url": "git+https://github.com/semantic-release/semantic-release.git"
@@ -25,9 +25,6 @@ const options = _.defaults(
  pkg.release,
  {
    branch: 'master',
-    fallbackTags: {
-      next: 'latest'
-    },
    debug: !env.CI,
    githubToken: env.GH_TOKEN || env.GITHUB_TOKEN,
    githubUrl: env.GH_URL
Author	SHA1	Message	Date
Stephan Bönnemann	5711e95c79	fix: revert undeclared breaking change	2015-08-23 22:34:10 +02:00
Stephan Bönnemann	e55b70dbf8	docs(README): list plugins and more talks	2015-08-23 22:26:35 +02:00
Stephan Bönnemann	399da06843	fix(condition-travis): remove need for python script travis_after_all	2015-08-23 00:57:37 +02:00
Stephan Bönnemann	ee2a7306e7	chore(travis): upload coverage from all jobs	2015-08-22 23:59:25 +02:00
Stephan Bönnemann	03534e51bc	fix(registry): be better at using the correct registry (relevant for npme) Closes #53	2015-08-22 23:33:36 +02:00
Stephan Bönnemann	85b35aaed3	chore(package): update last-release-npm to 1.2.1	2015-08-22 21:48:16 +02:00
Stephan Bönnemann	360a514171	feat: add fallbackTag functionality 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 could fallback to "latest" to determine the new "next" version. You can specify your mappings by adding "fallbackTags" to your `package.json`'s "release" field.	2015-08-22 21:43:22 +02:00
Stephan Bönnemann	90174c80a0	chore: adopt things for being back on master/latest	2015-08-22 20:16:34 +02:00