Thanks for opening your first issue at git-cliff! Be sure to follow the issue template! ⛰️

Hello, thanks for reporting this! 🐻

git-cliff uses the next_version crate for bumping the version. It might be better to ask the maintainer of that crate @MarcoIeni regarding if a new config option like that would be applicable or not :)

Hi, I'm truly sorry, but I'm not keen to add this option. It seems like a very unique use case, and I don't want to complicate the codebase to add it. Again, sorry!
I hope you find a workaround.

Orhun, if you want to implement this feature in git-cliff, I'm happy to help. E.g. if git-cliff has the features_never_bump_major set, and the library next_version returns a major bump, you could instead bump the minor version yourself.

I think the best way would be to have this functionality in next_version not to segregate things. But it's fine, I guess we can do it here too.

next_version returns a major bump, you could instead bump the minor version yourself.

How can we check if the returned version is major bump etc?

I think it would make the most sense if the default behavior would be according to: https://doc.rust-lang.org/cargo/reference/semver.html

Initial development releases starting with “0.y.z” can treat changes in “y” as a major release, and “z” as a minor release. “0.0.z” releases are always major changes. This is because Cargo uses the convention that only changes in the left-most non-zero component are considered incompatible.

The option breaking_always_bump_major is still ok and can be respected when set, alternatively it's default value could be auto

Could we maybe reuse the mechanism of MarcoIeni/release-plz@0a97ba4

Eg we specify feat to as a patch bump. So that it doesn't bump minor. 🤔

For breaking changes there could be something similar 🤔🤔 (I know it's very similar to what was proposed in this issue 😅).

Btw Orhun, I'm on mobile, so I'm not sure how you invoke next_version. But to check if a major has been updated, you could simply compare the two major versions (before and after the bump). The next_version crate exposes some functionalities to do the bump manually.

Have a look at:

• https://docs.rs/next_version/latest/next_version/trait.NextVersion.html#tymethod.increment_minor
• https://docs.rs/next_version/latest/next_version/enum.VersionIncrement.html#method.bump

mbodmer, the behavior you described is already the default 👍

Could we maybe reuse the mechanism of MarcoIeni/release-plz@0a97ba4

Eg we specify feat to as a patch bump. So that it doesn't bump minor. 🤔

For breaking changes there could be something similar 🤔🤔 (I know it's very similar to what was proposed in this issue 😅).

Btw Orhun, I'm on mobile, so I'm not sure how you invoke next_version. But to check if a major has been updated, you could simply compare the two major versions (before and after the bump). The next_version crate exposes some functionalities to do the bump manually.

Have a look at:

• https://docs.rs/next_version/latest/next_version/trait.NextVersion.html#tymethod.increment_minor
• https://docs.rs/next_version/latest/next_version/enum.VersionIncrement.html#method.bump

mbodmer, the behavior you described is already the default 👍

do you think adding a flag to specify the bump version type to use increment_xxx api in the next_version can be considered?

i come from standard-version and wonder if there is anything equivalent to --release-as in that

You can already do this without adding another option. Check out the links I posted above.

Sorry. Do you mean there is already a way to specify bump type in git-cliff? I saw your link to next_version and release-plz. I must be missing something here.

No, I'm talking about the next_version library. I didn't get your request was for git cliff 👍

No, I'm talking about the next_version library. I didn't get your request was for git cliff 👍

thanks, i made use of the api and made a pr in #744