Repository navigation
Not possible to use --get-next when changelog is enabled #1640
Description
Activity
I think this should be just a warning instead of an exception. @Lee-W @bearomorphism ?
This week is busy week. I'll take a look when I get bandwidth.
Reacted by Santiago Fraire WillemoesI took a quick glance and found this PR #1195 that initially added
--get-nextoption.Maybe need to investigate further why we treat such combination of parameter as
NotAllowedexception.I think it should just be a warning. I am working on a patch PR now.
The patch PR #1644 is ready. Please take a look
Please see #1645
agree a warning would be better 👍
We can also consider redesigning the option. For example, make
--get-nextto be a value of--dry-runcz bump --dry-run=new_version_onlyNormally, a
verboseorquietflag is used.cz bump --quiet --dry-run.
But, truth is, I would prefer to actually give more room to the commandversionand makebumpjust bump.I think we could use
versionto "operate" or "work" on versions, I've recently added the--majorand--minorflags to retrieve just that part of the version, but I think it could include:VERSION: Being able to provide a version incz version 0.1.0to perform operations.--next (increment)?: to show the next version (now--get-next). This would allow for an often common scenario, where you need to update some stuff before actually runningcz bump, and whereversion_filesdoesn't work. And you could retrieve a lot of information from it:
# retrieve the next major version, for example, # if you maintain a github action or a docker image, you could already have the name # of the next tag cz version --project --next --major # what would be the next minor version? here's your answer: cz version --project --next=MINOR
--tag: to actually retrieve the tag of the version with the template applied. If your tags looks like this:v0.1.0. You have to manually addvto your version right now. This command is useful to interact with git. If you want to retrieve the tagged commit, you could do:git show-ref $(cz version -p --tag). This is useful for auditing. And, if you have an old CI (e.g: jenkins), it would give an easy way for teams to check if the tag exists already before trying to bump. This commands, is the one I'm least sure about.--hash: to retrieve thehashof the commit. This can be used by security teams, in combination with the previous command, they can check if the hashes match.
In combination, some of this things could be done:
Perform some auditing:
tag_sha = $(cz version -p --hash) # ⬆️ This tag could be an output into a "compliance" tool or even the github release # ⬇️ Could be used by a security researcher to verify the hash, maybe later automated research_hash = $(cz version 0.1.0 --hash) if tag_sha != research_hash: warn("THREAT DETECTED")
Play with semver (it could help us with education):
cz version 0.1.0 --next=MAJOR # 0.2.0 # set major_version_zero = false cz version 0.1.0 --next=MAJOR # 1.0.0
Dynamically create something with the correct next version:
next_version=cz version -p --next node generate_terraform_docs.js $next_version cz bump --yesWhat do you'all think?
PD: On top of that, our current
commitizen-actionwouldn't be enough, as that action only allows for "bumping". I think we could introduce a newsetup-czaction which just makesczavailable to your job. Nowadays github actions work quite well, and it's quite simple to push by yourself.Example:
on: [push] jobs: bump: runs-on: ubuntu-latest steps: - uses: actions/checkout@v5 - uses: actions/setup-cz@v1 - id: next-version run: | next=$(cz version --major --next) echo "next_version=$next" >> $GITHUB_OUTPUT - run: | # update some stuff using ${{ steps.next-version.outputs.next_version }} - run: | cz bump --yes - run: | git config --global user.email "action@github.com" git config --global user.name "GitHub Action" git push --tags
Reacted by Wei Lee9 remaining items
It depends, I would say yes, but only if it really makes
bumpleaner. If it's just 2 lines it's not a problem.
Also, it would be nice to reviewbumpand see if there's anything else we can removeReacted by Tim HsiungMaybe we can rename the option
--files-onlyto--version-files-onlyReacted by Wei LeeMaybe we can rename the option
--files-onlyto--version-files-onlysounds like a good idea
I've built the setup-cz action, can you take a look? 🙏🏻
Reacted by Wei LeeThe new action is ready:
https://github.com/commitizen-tools/setup-czReacted by Tim Hsiung and Wei LeeI think the issue persists and
cz version -p --nextdoesn't exist. Shall I create a new ticket forcz version -p --nextinstead?
Because the idea is to deprecate--get-nextShall I create a new ticket for cz version -p --next instead?
yep, it would be better and more clear this way
Description
It's not possible to properly use
--get-nextwhen settingupdate_changelog_on_bump = true(is true).Steps to reproduce
.cz.tomlwithcz bump --yestouch foo.txt git add foo.txt git commit -m "fix: foobar"cz bump --get-nextThis would be fine, if there was a way to say
--changelog=falseor--no-changelog. But there's not. So this requires the user to "temporarly" set the flag in the.cz.tomlto false, which in a CI it's painful.Current behavior
There's no way to get the next version if the user has enabled
update_changelog_on_bumpin their settingsDesired behavior
I see 2 options, to discuss:
--no-changelogthat forcefully marks changelog=falseWhat do you think @Lee-W @noirbizarre ?
Screenshots
No response
Environment
Commitizen Version: 3.31.0
Python Version: 3.12.11 (main, Jun 3 2025, 15:41:47) [GCC 14.3.0]
Operating System: Linux