Standard-version: Version bumping isn't working properly based on Commit types

[dev-whiteflag]

Hi,

I'm using commitzen to take care of my commits, but when I make a release, standard-version isn't bumping based on my commits and only bumps patch once.

Logs

// standard-version log
> npx standard-version

√ bumping version in package.json from 0.1.0 to 0.1.1
√ bumping version in package-lock.json from 0.1.0 to 0.1.1
√ outputting changes to CHANGELOG.md
√ committing package-lock.json and package.json and CHANGELOG.md
warning: LF will be replaced by CRLF in CHANGELOG.md.
The file will have its original line endings in your working directory
warning: LF will be replaced by CRLF in package-lock.json.
The file will have its original line endings in your working directory
warning: LF will be replaced by CRLF in package.json.
The file will have its original line endings in your working directory

warning: LF will be replaced by CRLF in CHANGELOG.md.
The file will have its original line endings in your working directory
warning: LF will be replaced by CRLF in package-lock.json.
The file will have its original line endings in your working directory
warning: LF will be replaced by CRLF in package.json.
The file will have its original line endings in your working directory

√ tagging release v0.1.1
i Run `git push --follow-tags origin master && npm publish` to publish

```shellsession
// git cz log

git-cz

[email protected], [email protected]

? Select the type of change that you're committing: fix: A bug fix
? What is the scope of this change (e.g. component or file name): (press enter to skip) winston & package.json
? Write a short, imperative tense description of the change (max 71 chars):
(59) removed unused winston config file and updated package.json
? Provide a longer description of the change: (press enter to skip)

? Are there any breaking changes? No
? Does this change affect any open issues? No
[master 8dbe6ae] fix(winston & package.json): removed unused winston config file and updated package.json
5 files changed, 515 insertions(+), 2319 deletions(-)
create mode 100644 .versionrc
delete mode 100644 src/config/winston.js

But inside the Changelog.md, commits are being separated based on their types.

## Dependencies
```JSON
{
  "devDependencies": {
    "@babel/cli": "^7.8.4",
    "@babel/core": "^7.8.4",
    "@babel/preset-flow": "^7.8.3",
    "babel-eslint": "^10.0.3",
    "commitizen": "^4.0.3",
    "cz-conventional-changelog": "^3.1.0",
    "eslint": "^6.8.0",
    "eslint-config-airbnb-base": "^14.0.0",
    "eslint-plugin-flowtype": "^4.6.0",
    "eslint-plugin-import": "^2.20.1",
    "flow-bin": "^0.117.0",
    "standard-version": "^7.1.0"
  },
  "dependencies": {
    "app-root-path": "^3.0.0",
    "body-parser": "^1.19.0",
    "compression": "^1.7.4",
    "cors": "^2.8.5",
    "express": "^4.17.1",
    "helmet": "^3.21.2",
    "winston": "^3.2.1"
  },
  "config": {
    "commitizen": {
      "path": "./node_modules/cz-conventional-changelog"
    }
  }

[isantop]

I'm also seeing this behavior in one of my projects. If I make the commit a breaking change (using feat!: instead of feat:), then the minor version number is updated, but it's listed as a breaking change in the changelog. So it seems that every commit has an effect on the version component to the right of where it should (except for fix commits, which correctly bump the patch version).

[dev-whiteflag]

I tried to replicate your behavior but standard-version just bump patch without any reason. I find this very useful when working with new programmers so I would love to see this fixed.

[crusoexia]

Met this issue too.

Had a commit with BREAKING CHANGE: xxx follow the conventional commits, but it just does a minor version bump.

[dev-whiteflag]

BUMP, this module is really useful I would love to use it on a daily basis

[kaufmann42]

Still broken.

[itstueben]

Had the same problems that the minor version is not bumped by feat: commits

Using npx standard-version with the following .versionrc
````json
{
"types": [
{
"type": "feat",
"section": "Features"
},
{
"type": "fix",
"section": "Bug Fixes"
},
{
"type": "chore",
"hidden": true
},
{
"type": "docs",
"hidden": true
},
{
"type": "style",
"hidden": true
},
{
"type": "refactor",
"section": "Refactoring"
},
{
"type": "perf",
"hidden": true
},
{
"type": "test",
"section": "Test"
}
],
"preMajor": true
}

[dev-whiteflag]

Second bump, nothing on this huh? Almost no movement in this repo during this month. I don't want to try to fix the problem myself.

[stevemao]

Is there any repo to replicate this problem?

[kaufmann42]

I think I've found the problem. Prior to 1.0.0, it bumps patch only. Looking through the code in bump.js, it looks like this was an intended.

For those looking for a ❗️ Solution ❗️ , I recommend just bumping to v1.0.0 and then it should work fine.

[dev-whiteflag]

I wrongfully deleted the last comment, but @kaufmann42's response seems to be correct.
Anyone looking to test it, here's the repo: https://github.com/dev-whiteflag/standard-version-test

I'm going to try bumping to 1.0 and then testing patch, minor and major bumping; also, does standard-version count each feature commit when bumping or just bumps 1 into minor if a feature commit is present? It makes sense just bumping once if present.

[itstueben]

In my case the option " "preMajor": true" was hindering to bumping the major/minor versions

[Ostefanini]

@kaufmann42 you've just gave me a solution THAT WORKS. I've spent way to much time on this, it should be in red in the documentation !

[jorenbroekema]

@kaufmann42 @Ostefanini @dev-whiteflag

This is in line with conventional commits. If you did not release a v1 yet, you're still in alpha, which means it only bumps the patch number, and minor number for breaking changes. This allows you to do breaking changes in minors during alpha phase, and that's conventional also in the sense that if you put a dependency on ^0.6.0 it will only upgrade 0.6.x and not 0.x.x. Once it's v1, ^1.0.0 will upgrade 1.x.x and not only 1.0.x

[Kidsan]

As others have said, this should be made a bit more clear as I have also wasted significant time on this.

[jorenbroekema]

I do agree that both in conventionalcommits and in semver, there is not much clarity about this, and that standard-version needs to document more clearly what it does with regards to commit types & bumps for v0 majors.

Here's the problem:

• SemVer: Only says that for initial development you can use 0.y.z, e.g. start at 0.1.0 and increment the minor on releases. But it doesn't specify necessarily that minors in <0 major are for breaking changes. SemVer could commit on that specification I guess, but the reason they probably don't commit on that is because they specify that <0 major is "unstable" so basically "anything goes". Which is useful during initial development, to not think too much about public API and breaking changes. So you don't want to have a specification there. I agree with that at least.
• Conventionalcommits: If SemVer does not commit (pun not intended) on a spec for <0 majors (which I believe they shouldn't), it doesn't make much sense for them to commit to a guideline with regards to conventional commits for <0 majors
• Standard-version: 2 layers up we get to standard-version, where they have to choose something... Since SemVer is intentionally vague about v0 majors, and conventional commits probably therefore has no clear guidelines about what a fix or feat means for v0 majors, standard-version has to kind of choose a convention themselves here for v0 majors. Because it still needs to decide what kind of bump to do. Apparently they opt for a minor for commits with a commit body that contains BREAKING CHANGE:, and patch commits for everything else. I agree with this choice, but they should document it more clear.

[ttous]

SemVer specifies that:

• If there is a breaking change (whether it comes from a feature or a fix), bump the MAJOR.
• If not, if there is a feature, bump the MINOR.
• If not (there are only bugfixes), bump the PATCH.

We tag pre-production versions as 0.y.z because we want them to be considered unstable: _breaking changes_ happen a lot.

Therefore, perhaps we should follow these same rules, except for the first one: no matter if there is a breaking change or not, bump the MINOR if there is a feature, and if not, bump the PATCH.