A reliable way to determine whether a new version should be released

[AlesKrajnik]

Hi,

I am looking for a reliable way how to detect whether a new version should be published based on the commits. E.g. if I only ammend the documentation and then issue npx git-conventional-commits changelog, it produces something like this:

## **0.1.2**&emsp;<sub><sup>2024-07-27 (8695ecb12ef16977c92db2e3090aab77518b5300...eccee0fe03bc3806e978283e9582cb02d55decf8)</sup></sub>

*no relevant changes*
<br>

Similarly, npx git-conventional-commits version will produce a new version number even when there were no relevant changes.

I can of course do something like npx git-conventional-commits changelog | grep "\*no relevant changes\*", but that does not seem to be a sustainable solution.

Would it be possible to have the tool indicate that no new version is needed?

I can think of two different ways:

• creating a new command to detect whether "no relevant changes" were made
• adding a flag telling the version command to exit with an error in case there were no relevant changes

WDYT?

Thank you!

[qoomon]

Hi, I would go for

adding a flag telling the version command to exit with an error in case there were no relevant changes

[qoomon]

and add same flag for changelog command

[qoomon]

I just came up with another idea.

• add a version.commitTypes section to config file.
• based on that config the version command would suggests a new version or the most recent version.
  • add a flag like --error-on-no-change (we need to find something more catchy :-)) to version command
• changelog command will only produce a new entry if a new version is suggested

WDYT?

[AlesKrajnik]

As I see it, it's two questions:

1. Under what conditions should the version be bumped? Is it the same as "no relevant changes"?
2. How the tool should behave in case the version should not be bumped?

For the first question, I think it depends on what "no relevant changes" means, or specifically, whether "no relevant" changes" implies the version should not be bumped. If that would be the case, that would mean that if there are no commits with type defined in changelog.commitTypes, then there are "no relevant changes", which in turn means that the version should not be bumped.

The current behaviour is, however, that the version if always bumped, even when the type is not in changelog.commitTypes and also not in convention.commitTypes (https://github.com/qoomon/git-conventional-commits/blob/b39b5a189b8a4252a9a72abcfb85257c5eb7e5fe/lib/gitCommitConvention.js#L51).

So perhaps this should be clarified first - what constitutes no version bump? The official documentation does not really answer that question. It mentions that new version should be bumped for "feat" and "fix" types and all BREAKING CHANGES, however, it does not suggest anything e.g. for docs.

Perhaps we need a new configuration for it? Or can convention.commitTypes be used for it?

For the second question, I would say, it's really a binary question - the version should be either bumped or not. In this case, a simple CLI parameter would IMO do the trick.