Open m47730 opened 1 month ago
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 https://github.com/MarcoIeni/release-plz/commit/0a97ba40c8600190d0150239ffeed2eea900c53a
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:
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 https://github.com/orhun/git-cliff/pull/744
Is there an existing issue or pull request for this?
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 keep1.x.x
semver.So it could be very helpful to have an option like
features_never_bump_major
andbreaking_never_bump_major
or something else to assure that the bump is never for majorDesired 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