Add option for not bump major version

[m47730]

Is there an existing issue or pull request for this?

• I have searched the existing issues and pull requests

Feature description

Hi,
first of all: thanks for this tool, i love it!

I'm trying to briefly explain my needs:
in some scenario i have two version of a library (one for a language version and one for another), in this case i simply use master to advance and a branch release-1.x to keep the versioning for the old language and i want to keep 1.x.x semver.

So it could be very helpful to have an option like features_never_bump_major and breaking_never_bump_major or something else to assure that the bump is never for major

Desired solution

add some option to avoid major bumping

Alternatives considered

i could add some enforcing on ci or git hooks to avoid commit description with potential major bump, but is cumbersome and error prone

Additional context

No response

[welcome]

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

[orhun]

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 :)

[MarcoIeni]

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.

[MarcoIeni]

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.

[orhun]

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?

[mbodmer]

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

[MarcoIeni]

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 👍

[braineo]

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

[MarcoIeni]

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

[braineo]

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.

[MarcoIeni]

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

[braineo]

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