Standard-version: bug: chore commits increment patch version, but they shouldn't

[joefraley]

Unless I'm missing something this is a pretty severe bug. Version patches up for chore commits, maybe others.

Click here for minimal example repo here

Environment

"commitizen": "2.9.6",
"cz-conventional-changelog": "2.0.0",
"standard-version": "4.0.0"

Node 7

Repro

1. Add changes
2. npm run commit
3. set type as a chore, no breaking changes
4. npm run release
5. see the version increment when it shouldn't

Example actions

# commit some changes using commitizen
$ npm run commit
Line 1 will be cropped at 100 characters. All other lines will be wrapped after 100 characters.

? Select the type of change that you're committing: chore   # <---- a chore
? Denote the scope of this change ($location, $browser, $compile, etc.):
 dev
? Write a short, imperative tense description of the change:
 add npm run commit command
? Provide a longer description of the change:
 so people can test if they dont have git cz global
? List any breaking changes:

? List any issues closed by this change:

[master 79ab9f4] chore(dev): add npm run commit command
 1 file changed, 2 insertions(+), 1 deletion(-)

$ gst
On branch master
nothing to commit, working tree clean

# run standard
$ npm run release

> [email protected] release /Users/fraleyj/experiments/standard-v-demo
> standard-version

✔ bumping version in package.json from 0.0.0 to 0.0.1 # <--- bad
✔ outputting changes to CHANGELOG.md
✔ committing package.json and CHANGELOG.md
✔ tagging release 0.0.1
ℹ Run `git push --follow-tags origin master; npm publish` to publish

[Tapppi]

Uhh, you cannot (or rather shouldn't) release two versions with the same version number, so the increment is done to patch. I mean, sometimes you have to make chore changes and still release a fix, in these cases we usually write a custom message in the changelog afterwards.. What did you expect as a result?

[joefraley]

@Tapppi I expect the version tool to be a no-op if none of the current commits are a fix/feat/breaking change. Like commit 1000 chores/docs/perfs, run standard, see nothing change.

[bcoe]

@Tapppi @joefraley I _think_ this design decision is correct; a great example is making an edit to your README.md; I'll frequently do this, and want an updated page on npmjs.com -- so I'll want to increment a patch even though my commit was something like:

docs: fix my horrible spelling

@joefraley if you commit 1000 chores to master, and then run standard-version once, you'll only increment by one patch release.

[joefraley]

@bcoe I see. Your commit message suggests this to me:

(fix): spelling mistake in docs.

In which case everything would be fine.

I'm using standard to go to GitHub and NOT npm (otherwise I would use semantic-release) to control and track web site releases, but I appreciate that semver is designed specifically with tools in mind.

[joefraley]

Does that seem wrong to you? If your chore commit literally has the word "fix" in the body, it shouldn't be a fix commit?

I guess I'll just fork and make this configurable, but I had hoped for better reception to this idea. For example, this is how semantic-release treats (chore)'s, which is a popular workflow.

[Tapppi]

With semantic release, you are forced to have a very strict commit guideline. With standard version you choose when you release. If you're change doesn't affect any code etc., it is advised as a chore/docs etc. But you might still want to release it. Standard-version allows that, but it isn't possible with semantic release. It is simply the tradeoffs of similar but different workflows. I think that this is a strength, not a weakness, of standard-version.