Standard-version: CRITICAL: minor bumps being ignored

[prodigic]

954363d (HEAD -> feature/standard-version-release, tag: v2.0.0) chore(release): 2.0.0
aede9f4 feat: Broke the API
30acfe1 (tag: v1.3.0) chore(release): 1.3.0
f76aa30 feat: Forced a feature change
6836ceb (tag: v1.2.0) chore(release): 1.2.0
570f674 fix: Fixed a dummy thing...
cbc732d (tag: v1.1.0) chore(release): 1.1.0
d21e3ed build: no trailing space
701a018 (tag: v1.0.0) chore(release): 1.0.0
e251f2e chore: Installed standard-version for simple semantic release tagging

the version bump is wrong for commits d21e3ed (build:..) and 570f674 (fix:...) as should be a
patch level change but is bumping to next minor.

feat: works as expected
BREAKING CHANGE: works as expected

[prodigic]

bump!

This is a critical failure, it is not bumping patch versions without this it's not really useful.

[stevemao]

@prodigic Do you have a sample repo to replicate this behaviour?

[prodigic]

it's in a work repo . i'll try and get time to create a sample repo.

[rsevil]

Hi @stevemao,

I'm having the same issue as @prodigic it's always bumping minor instead of patch. Im using git over VSTS.

I began using this package today on an existing project that didn't follow any commit convention, so I'm worried if this issue is being caused by previous existing commits.

Also I think that the CHANGELOG is not being well generated, I'm attaching it as PDF document
CHANGELOG.pdf

Commit history:

What do you think?

[rsevil]

@stevemao I've done more tests and now it keeps bumping mayor releases although I've done only fix commits or feat commits

[rsevil]

@stevemao @prodigic my issue was that I was skipping the tag generation, so standard-version was generating bad version numbers.

[DHFW]

Same problem here. Just a fix: commit message bumps to minor instead of patch.

[bhovhannes]

I have the similar issue. Getting minor version bumps even if I have only fix: commits.
Any updates on this?

[thmsnhl]

I had the same issue and was able to resolve it by pushing the created tag for the minor version. After the tag was pushed npm run release created a patch version as expected.

My problem was that I did not push the tag which is being created by standard-version but wanted to create it later manually.

[tcrosen]

Going to post this here because it may help someone one day.

I had this problem _only on my CI server_. Version bump was minor no matter what I tried. Same repo/code on my machine produced correct results. Turns out the issue was that whatever Git plugin was running on my CI server did not fetch tags by default. The solution was to enable fetching tags.

[NetanelBasal]

Hey, the same issue in my repo. I have a fix commit, and the output is wrong. The minor version is bumped and the CHANGELOG also output the previous changes. Here's a screenshot:

[escapedcat]

@NetanelBasal was the 3.9.2 version tag pushed? As @thmsnhl wrote we made the mistake that we didn't push certain tags.
You screenshot says v.3.9.2...v3.11.0 which looks like standard-version isn't aware of your v3.10.0 somehow.

[NetanelBasal]

Yes, you can see the tags: https://github.com/datorama/akita

[escapedcat]

Yes, you are right. Also tried a dry-run on your repo and got the same result. Sorry I can't help.

[bcoe]

@prodigic this sounds like it was probably related to tags not being pushed and pulled ... this step is definitely annoying and error prone.

Did you ever get unblocked?

[thmsnhl]

@NetanelBasal I just had the same issue again on yesterday and I found a way to fix this.

What I realized was that I needed to merge the master-branch back into development (we are doing releases from development-branch) after creating the tag.

I just took a quick look at your repository and it seems like v3.10.0 did not find a way back into master and is being ignored when running release.

Also there seems to be a similar anomaly on version 3.7.0.

[bcoe]

@thmsnhl @prodigic @escapedcat, I've been working on a new release tool, inspired by standard-version, and using many of the same core libraries, but designed to run as part of CI/CD:

https://github.com/googleapis/release-please

This can help prevent accidents that occur as a result of not pushing tags, or working on a branch other than the default.

Otherwise, the way to avoid these bugs is to:

1. make sure tags are always pushed.
2. make sure tagging is performed on the default branch.