Standard-version: BREAKING CHANGE bumps minor version

Created on 14 Jul 2019 · 4Comments · Source: conventional-changelog/standard-version

I'm trying this tool in a couple of test branches, to simulate a real life scenario:
investigation/master simulates the master branch and investigation/tags-test simulates a feature branch.

Previous tag was v0.3.1. In the feature branch, a commit was created with the message:

feat: changed color to pink

BREAKING CHANGE: stuff is broken

I merged that into the master branch and I ran the script. This was the result:

I expected it to bump to version v1.0.0 but instead I got v0.4.0, like a regular feature.

Am I missing something when it comes to major versions?

Source

pdcmoreira

Most helpful comment

My bad. This actually follows the spec correctly, as it states that in major version 0 anything can break.
https://semver.org/#spec-item-4

So, for anyone looking for the same answers:

When version is below v1.0.0, any breaking changes will increment the minor version, because the 0 major version is considered unstable, so anything can break.
When the version is > v1.0.0, breaking changes will increment the major version.
To transition from an unstable version (< v1.0.0) to the first release (v1.0.0), considering your script in package.json is "release": "standard-version", you can do: npm run release -- -r major.

pdcmoreira on 15 Jul 2019

👍6

All 4 comments

My bad. This actually follows the spec correctly, as it states that in major version 0 anything can break.
https://semver.org/#spec-item-4

So, for anyone looking for the same answers:

When version is below v1.0.0, any breaking changes will increment the minor version, because the 0 major version is considered unstable, so anything can break.
When the version is > v1.0.0, breaking changes will increment the major version.
To transition from an unstable version (< v1.0.0) to the first release (v1.0.0), considering your script in package.json is "release": "standard-version", you can do: npm run release -- -r major.

pdcmoreira on 15 Jul 2019

👍6

Hi, I'm seeing the same behavior; I've already bumped my version to 1.1.0 as suggested above; what I see now is

>>>  git tag -l | grep v 
v1.1.0
>>> git commit -m "BREAKING CHANGE: testing semver"
[develop 179e964] BREAKING CHANGE: testing semver
 1 file changed, 2 deletions(-)
>>> npx standard-version 
✔ outputting changes to CHANGELOG.md
✔ committing CHANGELOG.md
✔ tagging release v1.1.1
ℹ Run `git push --follow-tags origin develop` to publish

What am I missing?
Thanks

judaltn on 25 Jul 2020

Hi, I'm seeing the same behavior; I've already bumped my version to 1.1.0 as suggested above; what I see now is

>>>  git tag -l | grep v 
v1.1.0
>>> git commit -m "BREAKING CHANGE: testing semver"
[develop 179e964] BREAKING CHANGE: testing semver
 1 file changed, 2 deletions(-)
>>> npx standard-version 
✔ outputting changes to CHANGELOG.md
✔ committing CHANGELOG.md
✔ tagging release v1.1.1
ℹ Run `git push --follow-tags origin develop` to publish

What am I missing?
Thanks

https://github.com/conventional-changelog/commitlint/issues/311#issuecomment-379962074

540692039 on 6 Jan 2021

Refering to https://www.conventionalcommits.org/en/v1.0.0/
adding exclamation mark feat!: babla worked for me. The footer alone was not a major bumpfor me aswell