Not possible to use --get-next when changelog is enabled

@Lee-W

Description

It's not possible to properly use --get-next when setting update_changelog_on_bump = true (is true).

Steps to reproduce

Create a .cz.toml with

version = "0.0.1"
version_scheme = "semver2"
update_changelog_on_bump = true

Create a commit and bump normally cz bump --yes
Add a new commit:

touch foo.txt
git add foo.txt
git commit -m "fix: foobar"

Try to get next version cz bump --get-next
Observe error

--changelog or --changelog-to-stdout is not allowed with --get-next

This would be fine, if there was a way to say --changelog=false or --no-changelog. But there's not. So this requires the user to "temporarly" set the flag in the .cz.toml to 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_bump in their settings

Desired behavior

I see 2 options, to discuss:

Do not block on this setting when it's enabled
Add a new flag --no-changelog that forcefully marks changelog=false

What 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

@Lee-W

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.

I took a quick glance and found this PR #1195 that initially added --get-next option.

Maybe need to investigate further why we treat such combination of parameter as NotAllowed exception.

https://github.com/commitizen-tools/commitizen/pull/1195/files#diff-920733205b591ccb6aded23a60aba1c20600036d38b5c224e27da47cf09ffb60

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-next to be a value of --dry-run

cz bump --dry-run=new_version_only

Normally, a verbose or quiet flag is used. cz bump --quiet --dry-run.
But, truth is, I would prefer to actually give more room to the command version and make bump just bump.

I think we could use version to "operate" or "work" on versions, I've recently added the --major and --minor flags to retrieve just that part of the version, but I think it could include:

VERSION: Being able to provide a version in cz version 0.1.0 to 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 running cz bump, and where version_files doesn'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 add v to 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 the hash of 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 --yes

What do you'all think?

PD: On top of that, our current commitizen-action wouldn't be enough, as that action only allows for "bumping". I think we could introduce a new setup-cz action which just makes cz available 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

It depends, I would say yes, but only if it really makes bump leaner. If it's just 2 lines it's not a problem.
Also, it would be nice to review bump and see if there's anything else we can remove

Maybe we can rename the option --files-only to --version-files-only

Maybe we can rename the option --files-only to --version-files-only

sounds like a good idea

I've built the setup-cz action, can you take a look? 🙏🏻

commitizen-tools/setup-cz#1

The new action is ready:
https://github.com/commitizen-tools/setup-cz

now the action is there and #1645 is merged. I think we can close this one

I think the issue persists and cz version -p --next doesn't exist. Shall I create a new ticket for cz version -p --next instead?
Because the idea is to deprecate --get-next

Shall I create a new ticket for cz version -p --next instead?

yep, it would be better and more clear this way

Navigation Menu

Repository navigation

Not possible to use `--get-next` when changelog is enabled #1640

Description

Steps to reproduce

Current behavior

Desired behavior

Screenshots

Environment

9 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Not possible to use --get-next when changelog is enabled #1640

Description

Description

Steps to reproduce

Current behavior

Desired behavior

Screenshots

Environment

Activity

woile commented on Nov 10, 2025

bearomorphism commented on Nov 10, 2025

bearomorphism commented on Nov 10, 2025

bearomorphism commented on Nov 10, 2025

bearomorphism commented on Nov 10, 2025

bearomorphism commented on Nov 10, 2025

Lee-W commented on Nov 11, 2025

bearomorphism commented on Nov 12, 2025

woile commented on Nov 12, 2025

9 remaining items

woile commented on Nov 19, 2025

bearomorphism commented on Nov 19, 2025

Lee-W commented on Nov 19, 2025

woile commented on Nov 20, 2025

woile commented on Nov 21, 2025

Lee-W commented on Nov 30, 2025

woile commented on Nov 30, 2025

Lee-W commented on Nov 30, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Not possible to use `--get-next` when changelog is enabled #1640