version bump with breaking change, release candidate (rc0) didn't increment major version number #472
Comments
@Lee-W, thank you for taking the time to review. I don't believe it's related to #415 as this issue pertains to bumping when there is no commits with a type that would bump the version. As seen in my commit history above, I had more than enough commits to bump the version. However in my case a major version bump never occurred. As for #454 i again do not see this as related, as my changelog is working as intended. My issue is, TLDR. Current version was a rc, a breaking change commit was added. However the version bump was not a major version bump, it was an rc to a non rc bump (0.3.0rc1 -> 0.3.0 should have been 0.3.0rc1 -> 1.0.0). A breaking change, regardless of version should ALWAYS bump the major version number. |
|
If that's the case, I think we might need more time to dig into this issue. My guess is that it might be related to semver_generator. Thanks for your report and detailed description! |
|
That does look like it is the place that prevents the increment after reviewing sem ver 1.0.0 it is clear when a MAJOR bump should occur as a breaking change is supposed to do. I think this patch to https://github.com/commitizen-tools/commitizen/blob/master/commitizen/bump.py#L78-L98 maybe what is required. However am not aware of how the prefix is added, so this patch maybe incomplete. + # regardless of release prefix, if any.
+ # A BREAKING CHANGE must increment MAJOR version
+ # Example: 0.5.0rc1 -> 1.0.0rc1 for prerelease
+ # Example: 0.5.0rc1 -> 1.0.0 for non-prerelease
+ if increment == MAJOR:
+ increments_version[MAJOR] += 1
+ increments_version[MINOR] = 0
+ increments_version[PATCH] = 0
+
# This flag means that current version
# must remove its prerelease tag,
+ # before a PATCH/MINOR increment
- # so it doesn't matter the increment.
# Example: 1.0.0a0 with PATCH/MINOR -> 1.0.0
- if not version.is_prerelease:
+ if not version.is_prerelease && increment != MAJOR:
- if increment == MAJOR:
- increments_version[MAJOR] += 1
- increments_version[MINOR] = 0
- increments_version[PATCH] = 0
- elif increment == MINOR:
+ if increment == MINOR:
increments_version[MINOR] += 1
increments_version[PATCH] = 0
elif increment == PATCH:
increments_version[PATCH] += 1
return str(
f"{increments_version['MAJOR']}."
f"{increments_version['MINOR']}."
f"{increments_version['PATCH']}"
)
A patch is also required to the increment detection, as per my command output above the increment detected for the version bump was minor, not major. so there also appears to be a bug within this logic too. The above would enable a workflow of (example):
|
|
In this context please be careful with the |
|
Is this issue still happening? Could you check against commitizen v3? thanks |
Lee-W
added
issue-status: wait-for-response
and removed
pr-status: wait-for-review
labels
|
applogies for the tardy reply. no i wont be testing and wasting my time when the logic is still the same however with different line numbers Lines 102 to 121 in 3ececac REF: #472 (comment) |
Description
A breaking change was introduced in commit 5f273ce23a331eaf11623207ec4aba8b856c14f0. Current version was
0.3.0rc1on the next version increment the version only incremented to0.3.0when it should have incremented to1.0.0repo link:
Gitlab: https://gitlab.com/nofusscomputing/projects/gitlab-ci/
Github: https://github.com/NoFussComputing/gitlab-ci/
Git log with the commits in question including tags
Steps to reproduce
git clone https://gitlab.com/nofusscomputing/projects/gitlab-ci.gitgit checkout development
git fetch --tagsdelete all tags after tag
v0.3.0rc1git reset f455eb2e278eb3fd7f9dde693587393ea2783cff --hardrun commands to bump version
Adding a commit with a
!after the type still failsCurrent behavior
Does not do a
MAJORversion increment when breaking change introduced.Desired behavior
breaking change, should always increment the
MAJORversion number regardless of current version.Environment
cz version:
commitizen version: (test machine 2.17.13) however CI uses current as of date of job. Also tested with cz-0.0.0.0.dev20200924CI Build LogCustom Module cz_nfc (this is the version at the time of the failed version bump) however even the Current cz_nfc module does not make a difference
python3 -c "import platform; print(platform.system())"
test machine:
$ python -c "import platform; print(platform.system())" LinuxCI Build Log #1497464492
operating system: Linux (Gitlab CI: Linux gitlab runner using docker image python 3.6)
cz version --report $ cz version --report usage: cz [-h] [--debug] [-n NAME] {init,commit,c,ls,example,info,schema,bump,changelog,ch,check,version} ... cz: error: unrecognized arguments: --report (dev_env) $I have reviewed the docs to ensure that I haven't done anything wrong. However to no avail.
The text was updated successfully, but these errors were encountered: