semantic-release: Problem: ENOCHANGE There are no relevant changes, so no new version is released.

IMHO (respectfully) ENOCHANGE possibly shouldn’t be a thing. “no change” is a valid and expected state, not an error condition. using ENOCHANGE as a mean of control flow seems like misuse of the Error construct.

Grateful for this project, keep up the good work 😃

Some of them may be debatable, but docs definitely changes the user experience.

If there is no release on npm, semantic-release will analyze all the commits in your repo to figure out if a release is necessary. A new release (the initial 1.0.0) will happen only if the commit-analyzer determines there is a commit in the history that should trigger a release. By default it’s: perf, feat, fix or a breaking change.

If your repo contains only commits that doesn’t trigger a release, then the initial won’t happen. This is the expected behavior as we don’t want to make the initial release until there is actually something to release. For example if your firsts commits are something like chore: Add license, ci: Set up Travis etc we don’t want to release. Once you push a commit like feat: Initial release for example the release will happen.

In addition, the releases rules are now completely customizeable: see commit-analyzer#release-rules

Here is a config that would trigger a patch release for commits that starts with docs(readme):

{
  "release": {
    "analyzeCommits": {
      "preset": "angular",
      "releaseRules": [
        {"type": "docs", "scope": "readme", "release": "patch"}
      ]
    }
  }
}

This issue cover a lot of things but I think they should be covered by this new plugin configuration. Some other problems are mentioned but there is corresponding issue already open. Feel free to open a new issue if it’s not the case.

i’m unclear on how the intent is supposed to work. why would “no change” be a non-zero exit code? what’s the convention such that i can merge things into master that arent supposed to cut new releases? i dont want CI failing because it discovered “hey, there’s nothing new.” in fact, yes, i’m aware there’s nothing new, and that’s ok–no reason to exit 1! just askin’ what i’m missing, here

@glebec AFAIK most people read the docs on github, and don’t want to look at some completely unformatted markdown in their node_modules folder.

You can work around this using https://github.com/fullcube/customizable-commit-analyzer

Nope. This is just default Travis CI behavior.

First it runs all tests. A non-zero exit here will fail build. If there was no error with tests, Travis will mark build as passing and run after success scripts. Result of after success scripts won’t affect build state.

I think semantic-release should throw warn instead of error for such case.

@MoeSattler the README.md does change what is shown on npmjs.com. So I guess I have to change it to a fix type for now.

@thiagofelix no it’s a different case. The problem is that commit analyzer will consider a new version only if there are commits of type feat or fix. I already sent a pull request to fix this: https://github.com/semantic-release/commit-analyzer/pull/13

If you’d like more details please check the conversation here: https://github.com/semantic-release/commit-analyzer/issues/12#issuecomment-203166512

Thanks, cheers!