bug: chore commits increment patch version, but they shouldn't
See original GitHub issueUnless 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
- Add changes
- npm run commit
- set type as a chore, no breaking changes
- npm run release
- 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
> cz-meridian@0.0.0 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
Issue Analytics
- State:
- Created 7 years ago
- Reactions:3
- Comments:7 (3 by maintainers)
Top Results From Across the Web
conventional commit messaging - Conventional Commits
A specification for adding human and machine readable meaning to commit messages.
Read more >Enhance your git log with conventional commits
I think we shouldn't confound git commit with ctrl + s . A git log should ... fix: Fix a bug (equivalent to...
Read more >Semantic Versioning - The Blue Book
Patch version Z (x.y.Z | x > 0) MUST be incremented if only backwards compatible bug fixes are introduced. A bug fix is...
Read more >Version Incrementing - GitVersion
Semantic Versioning is all about releases, not commits or builds. This means that the version only increases after you release, this directly conflicts...
Read more >How do you avoid updating the version number on every ...
Commits shouldn't be broad, and only fix/change one or two things. Got 3 unrelated bug fixes? Give each their own commit. Updates should...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
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
.@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.