Version bumping isn't working properly based on Commit types

[honeymoan]

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

// 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

{
  "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).

[honeymoan]

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.

[honeymoan]

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

{
  "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
}

[honeymoan]

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.

[honeymoan]

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 minor bumps in < 1.0.0 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 < 1.0.0 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 < 1.0.0 bumps (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 < 1.0.0 bumps
• 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 choose a convention themselves. 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 clearly.

[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.

[rklec]

Any news here?

The SemVer 2.0.0 spec days:

How should I deal with revisions in the 0.y.z initial development phase?

The simplest thing to do is start your initial development release at 0.1.0 and then increment the minor version for each subsequent release.

However, this is only the FAQ part and a suggestion (i.e. "The simplest thing to do").

What the spec really defines is:

4. Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

It explicitly allows y (the minor version) to change.

The thread in https://github.com/semver/semver/issues/333#issuecomment-463390138 tackles this issue and I guess this summarized the current state quite good:

There is nothing explicit about what the rules for initial development should be.

As such, IMHO, there should at least be a flag/configuration option in .versionrc to also bump minor in the initial development stage (<1.0.0) just like you would do when it is stable. Otherwise the version always stays at 0.0.z until 1.0.0 which feels awkward to me and let me to find this issue as it was clearly unexpected/not what I thought standard-version would behave.

Both variants are clearly in line with the spec, so IMHO, standard-version should support it. You could even, and that may be discussed, doing that new behavior by default. Or better introduce it as optional for now and later make it a default, if you want to go that way.

[rklec]

BTW SemVer 2.0.0 also says:

The simplest thing to do is start your initial development release at 0.1.0 and then increment the minor version for each subsequent release.

That's not the patch version (0.0.z), as Standard-Version currently does! Minor would make more, sense IMHO, but still the usual bumping behavior would be better. (0.y.0)

[jorenbroekema]

@rklec

I prefer the current behavior for < v1.0.0:

• minor bump for breaking changes
• patch bump otherwise

The reason being that I want to have a clear separation in my changelog between non-breaking changes and breaking changes in my alpha versioned package. This separation is more important than the separation between fixes (patch) and features (minor in > v1.0.0)

[rklec]

Ahhh that is the current behavior? Then I misunderstood it again and never experienced it given I do not mark breaking changes/use them so often (in v. < 1.0.0) Okay so, then this should be another possibility.