Open jon-nfc opened 2 years ago
Lee-W
commented
2 years ago Hi @jon-nfc , thanks for reporting. I've confirmed it. This might relate to https://github.com/commitizen-tools/commitizen/issues/415 and https://github.com/commitizen-tools/commitizen/pull/454 what we've not yet had the time to dig into it.
jon-nfc
commented
2 years ago Hi @jon-nfc , thanks for reporting. I've confirmed it. This might relate to #415 and #454 what we've not yet had the time to dig into it.
@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.
Lee-W
commented
2 years ago 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!
jon-nfc
commented
2 years ago 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):
current release 0.5.0rc1
work is done, non-breaking change and version bump, version increment to 0.5.0rc2
now if a breaking change is commited, version bump, version increment 0.5.0rc2 -> 1.0.0rc1 for prerelease and 0.5.0rc2 -> 1.0.0 if non-prerelease
jenstroeger
commented
1 year ago In this context please be careful with the --major-version-zero flag.
woile
commented
1 year ago Is this issue still happening? Could you check against commitizen v3? thanks
jon-nfc
commented
1 year ago @woile,
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 https://github.com/commitizen-tools/commitizen/blob/3ececac37470726e357a3c22c140a0f01cb4ec74/commitizen/bump.py#L102-L121
REF: https://github.com/commitizen-tools/commitizen/issues/472#issuecomment-1015043617
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
``` bash $ git log commit 389bc08d7686153fb374aa83d440c35c9b4eac90 (HEAD -> development, tag: v0.3.0) Author: NFC CISteps 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.dev20200924[CI Build Log]()Custom 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:
CI Build Log #1497464492
operating system: Linux (Gitlab CI: Linux gitlab runner using docker image python 3.6)
I have reviewed the docs to ensure that I haven't done anything wrong. However to no avail.