Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly
Sign up
Appearance settings

feat(version): add MANUAL_VERSION, --next and --patch to version command #1724

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
bearomorphism wants to merge 1 commit into commitizen-tools:master
base: master
Choose a base branch
Loading
from bearomorphism:feat-next-version

Conversation

@bearomorphism
Copy link
Collaborator

@bearomorphism bearomorphism commented Dec 12, 2025 •
edited
Loading

Closes #1679

Manually tested and added test cases, the result LGTM.

Copy link
Collaborator Author

@Lee-W I already ran pytest tests/commands/test_version_command.py -n auto --regen-all to regenerate the test files, but the pipeline still fails. (The tests passed on my machine)

Do you have any ideas why this happen

version = f"{version_scheme.minor}"
out.write(version.major)
return
if self.arguments.get("minor"):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I realize now that this creates problems with the (not)monotonic kind of versions (and possible non-semver). I'm not sure what to do about it.

I think for now it's fine that if you diverge too much from semver in your custom version scheme, then you won't get the full range of features.

bearomorphism reacted with thumbs up emoji
Copy link
Member

woile commented Dec 12, 2025

There was a way to run all the pre-commits, but I don't remember how it works 😅

assert expected_version in captured.out


def test_next_version_invalid_version(config, capsys):
Copy link
Member

@woile woile Dec 12, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what about having a parametrize of the combinations that should fail:

@pytest.mark.parametrize(
 "args",
 [
 # incomplete list:
 {"next"},
 # ...
 {"--verbose", "next"}
 ]
)

Copy link
Collaborator Author

@bearomorphism bearomorphism Jan 7, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good.

Copy link
Member

woile commented Dec 12, 2025

Nice to see this going forward 🎉

Copy link

codecov bot commented Dec 13, 2025 •
edited
Loading

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.92%. Comparing base (193859b) to head (4a9a5da).

Additional details and impacted files 
@@ Coverage Diff @@
## master #1724 +/- ##
==========================================
- Coverage 97.93% 97.92% -0.01% 
==========================================
 Files 60 61 +1 
 Lines 2611 2654 +43 
==========================================
+ Hits 2557 2599 +42 
- Misses 54 55 +1

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Collaborator Author

@Lee-W I already ran pytest tests/commands/test_version_command.py -n auto --regen-all to regenerate the test files, but the pipeline still fails. (The tests passed on my machine)

Do you have any ideas why this happen

I see why the test failure happens. Please see my other PR #1726 .

Copy link
Collaborator Author

I will rebase this branch after #1726 is merged. The test failure should be resolved then.

@bearomorphism bearomorphism force-pushed the feat-next-version branch 3 times, most recently from 8d938d2 to f9afbd4 Compare December 14, 2025 14:08
@bearomorphism bearomorphism changed the base branch from v4-11-0 to master December 29, 2025 11:11
@bearomorphism bearomorphism force-pushed the feat-next-version branch 3 times, most recently from 3b48a33 to b07121e Compare January 3, 2026 17:24
Copy link
Member

@noirbizarre noirbizarre left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's an interesting feature, one that I would totally use!

Also, I never realized that the version command was doing totally different things depending on the flags 😅
So maybe it's the occasion to have a dedicated --version flag and have the version command focusing on the the project versioning and not the Commitizen version. It would be cleaner, easier to understand and more standard. WDYT ?

Note

I would not remove the Type aliases as it makes the PR bigger than it should and it introduce a breaking change (and reading the PR and issues, we know that it has been used by some users for some custom version schemes).

Copy link
Member

Also, the enumn part seems to overlap with #1518, so maybe #1518 should go first so this PR can reuse the Increment enum

Copy link
Collaborator Author

Also, the enumn part seems to overlap with #1518, so maybe #1518 should go first so this PR can reuse the Increment enum

I would prefer to merge this before #1518 because it is a bit larger than this PR.

So maybe it's the occasion to have a dedicated --version flag and have the version command focusing on the the project versioning and not the Commitizen version. It would be cleaner, easier to understand and more standard. WDYT ?

+1. As a user, I often run cz --version and end up seeing an error. We can create another work item about adding the dedicated flag and then deprecate cz version --commitizen and other removable flags in the next major version.
noirbizarre reacted with thumbs up emoji

Copy link
Member

woile commented Jan 5, 2026 •
edited
Loading

We had a --version in the past, but it was replaced by version, do you remember why @Lee-W ?
It would be a breaking change if we go that route. If agreed, I can add it as a different task on the parent issue tracking this work #1677

noirbizarre reacted with thumbs up emoji

@bearomorphism bearomorphism force-pushed the feat-next-version branch 4 times, most recently from 575468d to 3af1a57 Compare January 6, 2026 13:24
@bearomorphism bearomorphism marked this pull request as ready for review January 6, 2026 13:26
@bearomorphism bearomorphism force-pushed the feat-next-version branch 2 times, most recently from 4b6a441 to c3d27c9 Compare January 6, 2026 14:01
@bearomorphism bearomorphism changed the title (削除) feat(version): add MANUAL_VERSION, --next and --patch to version comm... (削除ここまで) (追記) feat(version): add MANUAL_VERSION, --next and --patch to version command (追記ここまで) Jan 6, 2026
Copy link
Collaborator Author

@woile @noirbizarre @Lee-W
Could you review and merge this PR, so we can move on to other cz version related task? Thanks!

Copy link
Member

woile commented Jan 12, 2026

There are some open conversations still

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@woile woile woile left review comments

@Lee-W Lee-W Awaiting requested review from Lee-W Lee-W is a code owner

@noirbizarre noirbizarre Awaiting requested review from noirbizarre noirbizarre is a code owner

Requested changes must be addressed to merge this pull request.

Assignees

No one assigned

Labels

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Add support for cz version <version_arg>

AltStyle によって変換されたページ (->オリジナル) /