Standard-version: Don´t generate a release for specific types of changes like chore or docs

[brpaz]

Hello. semantic-release ignores some commits like "chore, "docs", etc and does not generate a new release.

It would be great for semantic-version to do the same. And since these types of commit doesnt seem to appear in the Changelog either, I now have a project CHANGELOG that looks like this: https://github.com/brpaz/do-snapshot-pruner/releases with a lot of empty releases.

[GitGangGuy]

While the empty changelog releases are pretty ugly, from what I understand (I haven't worked intensely with standard-version) standard-version doesn't deploy/release changes anywhere by itself (setting it apart from semantic-release).
What are you using to publish your commits? Refer to their issues instead then.

[brpaz]

The releases for this particular project are created with goreleaser but the content is the CHANGELOG.md file generated by standard-version

[arielwb]

I'm also searching for something like this.
My use case is that I want to run the release command in every merge, but I don't want to do nothing if the commit types are chore, docs, style etc.

I've been trying to achieve this using the package conventional-recommended-bump to check if I should release or not, but the result is aways a patch on this commit types.

It would be great if we have control over this by some configuration option.

If there is a config and I missed, please, show me the way ;)

[jorenbroekema]

In my workflows I use standard-version for every push to master, and do npm publish as well. If there was no version bump in my package.json, npm publish fails. which is a great workflow, because it means only commits that trigger version bumps get published automatically.

However, standard-version always bumps regardless of whether you even had commits that mandate a release. So yeah, I think this feature is definitely needed, because now I just use a dev branch to do my chores on, and only merge to master if I intend on releasing. Which is in my mind not continuous integration because my chores or docs/demo updates don't make it to master continuously, they are periodically merged when I do a fix or feature that mandates a version bump. This is a shame :(.

Hopefully the maintainers agree that they want this feature, if they share a bit of guidance on how to implement I would be happy to make a contribution. Perhaps also a field in the standard-version config file where you can do bump: false for commit types.

[derekgreer]

+1

I have a CI build that runs standard-version, creates NuGet packages based on the updated version, and then publishes the new packages. I have my publish configured to ignore errors if the version is already published, so you could run the same build over and over and it _should_ produce the same versioned library. That would work except for the fact that standard-version bumps the version regardless of whether there are any commits it recognizes as triggering a version increment. I would think that really should be the default behavior as well, but that aside there needs to be a switch to decide on whether you want this behavior or not.

[jorenbroekema]

Just in case people are looking for a workaround solution:

Inspired by https://github.com/atlassian/changesets , you could create a file when you intend to release your package, and in Github Actions or similar CI, only run your release workflow when this file is present, using https://help.github.com/en/actions/reference/workflow-syntax-for-github-actions#onpushpull_requestpaths

And then in this workflow at the end, you remove the file and commit + push that back to git.

This way you can merge to master whenever you like and leverage your CI to only run standard-version when you actually intend on releasing.

[danpintara]

Looks like this issue is similar to #192.

[derekgreer]

I don’t want a work around. Just don’t bump versions if there are no feat, fix, or breaking changes.

[jorenbroekema]

I don’t want a work around. Just don’t bump versions if there are no feat, fix, or breaking changes.

I know, using another tool is not a fix for this issue. But since this issue doesn't seem to get any traction by the maintainers, an alternative is good to have.

[jcornaz]

Of course. And thank you very muhc @jorenbroekema for sharing your work around!

@conventional-changelog Is there any chance we can see this issue solved?

[amphro]

Bump on this. The readme says it follows Conventional Commits Specification which says that fix:, feat: and BREAKING CHANGE correlates to bumps in semantic versioning. The other types don't. It would be nice to actually follow Conventional Commit Specification.

[derekgreer]

@amphro I'd say this is probably how it _should_ have worked from the outset, but given the tool is more than 4 years old and has a large user base I'd say changing it to NOT bump the PATH portion of the version by default would likely be quite disruptive for many. If this were an actual library, such a breaking change would be more acceptable since properly reflecting breaking changes for a semantic versioning library using the semantic version is what you'd expect. Being often used as a globally-installed command line tool or via npx, it's probably more important to strive for backward compatibility.

[amphro]

I would argue that is what major version bumps are for, but fair enough. As a maintainer on a widely used CLI, I also get the "bug has become a feature" where the bug is debatable to begin with. The smallest changes can cause a lot of headaches for customers and to your point, this is not a small change to most users.

With that said, it seems like this can still be a command-line option, environment variable, or some other configuration. For example, like how semantic-release does it. Would that be something that would be considered? Doing it manually seems less than ideal.