-
-
Notifications
You must be signed in to change notification settings - Fork 280
Bump increments to new pre-release version from pre-release version when it wouldn't from final version #688
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
Comments
I just noticed the same behavior: with the Furthermore, it increments on non-bump commit titles like
There’s currently no official specification on how conventional commits should increment under a pre-release. However, comment conventional-commits/conventionalcommits.org#398 (comment) makes a sensible suggestion for incrementing pre-release version numbers. Any plan for |
I'm really not that convinced. I think we need a more formal definition of what a pre-release is and a longer explanation. I find it strange the possibility to go from I'm not against doing something about it per-se, but I think we need further thought on the topic. What about controlling the version with |
That's exactly what I expect if the commits require it. A IOW, Commitizen should use changes since the previous release to determine if a new release is required but it should use changes since the previous final release to determine if the increment should be a patch, minor, or major bump. |
What @rpatterson said. Whether a user publishes a release from a pre-release or not is a different matter. The question really is: given a pre-release tag & version and a series of Currently it doesn’t, see above. |
I realized I haven't already said it, but this specific tool is the closest I've found, including other tools (JS inclusive), to getting me to one-person CI/CD release publishing workflows based on conventional commits. So this nit-pick comes from real love. |
This makes sense, I think we can work with something like that. I'll take a deeper look after holidays (june), unless someone wants to focus on it. does this table summarize it well?
|
Awesome, but just to be clear, I don't think of opening an issue as a demand that anyone in particular do something about it. ;-)
Yup, looks right to me. Though personally I find it hard to get the point from that table. The prose description is more clear for me. |
@woile see also conventional-commits/conventionalcommits.org#398 (comment). |
A note to avoid duplication — we’re working on a change for this issue. |
Description
Running
$ cz bump --prerelease beta
when the current version is a previous pre-release bumps the version even when there are no commits that would require it, e.g. onlybuild
/ci
commits.Steps to reproduce
v0.0.1
$ git commit -m "ci: CI-specific change not requiring release"
$ cz bump --prerelease beta
-> Refuses to bump the version as expected$ git commit -m "fix: Prospective fix requiring beta testing"
$ cz bump --prerelease beta
-> Bumps tov0.0.2b0
as expected$ git commit -m "build: Local devel change not requiring release"
$ cz bump --prerelease beta
-> Bumps unexpectedly tov0.0.2b1
Current behavior
Maintainers can't use
$ cz bump
as a tool to interpret conventional commit messages to determine if a release is required when the current version is a pre-release. When some contributors are makingbuild: ...
/ci: ...
changes while features are in beta testing, this behavior results in a lot of noisy, meaninglessv#.#.#b9999999....
bump commits, tags, and releases.Desired behavior
Maintainers should be able to use
$ cz bump
, or$ cz ...
in some other form, to determine if the conventional commit messages since the last pre-release require a new pre-release.Environment
(build) rpatterson@rpatterson:~/src/devel/python-project-structure$ cz version --report Commitizen Version: 2.42.1 Python Version: 3.10.6 (main, Nov 14 2022, 16:10:14) [GCC 11.3.0] Operating System: Linux
The text was updated successfully, but these errors were encountered: