Repository navigation
Bump increments to new pre-release version from pre-release version when it wouldn't from final version #688
Description
Activity
- added a commit that references this issue
on Mar 16, 2023 I just noticed the same behavior: with the
--prereleaseswitch commitizen only ever increments the version once and then continues to bump the pre-release counter.Furthermore, it increments on non-bump commit titles like
chore:and it then also skips other bumps:- start at version
0.1.0 git commit --allow-empty --message 'fix: a fix'cz bump --prerelease alpha→ bumps to0.1.1a0which is okgit commit --allow-empty --message 'feat: a feature'cz bump --prerelease alpha→ bumps to0.1.1a1which is incorrect, I would have expected0.2.0a0and we lost the “feature” bumpgit commit --allow-empty --message 'chore: a chore'cz bump --prerelease alpha→ bumps to0.1.1a2which is surprising, but I guess could be ok (if the rest of the increments would work)git commit --allow-empty --message 'feat!: a breaking change'cz bump --prerelease alpha→ bumps to0.1.1a3which is incorrect, I would have expected1.0.0a0(assuming we’re not in development mode to keep major version at zero) and we lost the breaking bump
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
czto implement that soon?Reacted by Ross Patterson- start at version
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
0.1.1a1to0.2.0a0to1.0.0a0to2.0.0a0without ever doing a non-pre-release, feels like a strange workflow. Under which circumstance someone would develop a 3.0 without ever releasing 1.0?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
--increment? forcing a more manual workflow?cz bump --increment MINOR --prerelease alpha, we could have a command likecz bump --increment-onlyin case someone wants to automate based on the commits, and from there:cz bump --increment $(cz bump --increment-only) --prerelease alpha?I find it strange the possibility to go from 0.1.1a1 to 0.2.0a0
That's exactly what I expect if the commits require it. A
v0.1.0final release means a feature was released, right? If then a bug fix is released as a pre-release, it should bev0.1.1a1because if it checks out and goes to final release, then that would bev0.1.1, right? If beforev0.1.1a1makes it to final release, someone merges a feature, then a pre-release for that should not bev0.1.1a2because when it does make it to final release it should not bev0.1.1. When it gets to final release it should bev0.2.0, hence a pre-release containing that feature should bev0.2.0a0. If then, however someone merges another feature and a finalv0.2.0hasn't been released yet, then the pre-release for that second feature should bev0.2.0a1, notv0.3.0a0.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
fix:andfeat:andchore!:commits canczbump the next version correctly?Currently it doesn’t, see above.
Reacted by Ross Patterson, Wei Lee and Constantin PonfickI 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.
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.
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?
version fix feat breaking 0.1.1a0*a10.2.0a00.2.0a0or1.0.0a0(depending on major_version_zero)0.1.0a0*a1*a10.2.0a0or1.0.0a0(depending on major_version_zero)1.0.0a0*a1*a1*a1This 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.
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. ;-)
does this table summarize it well?
version fix feat breaking
0.1.1a0*a10.2.0a00.2.0a0or1.0.0a0(depending on major_version_zero)
0.1.0a0*a1*a10.2.0a0or1.0.0a0(depending on major_version_zero)
1.0.0a0*a1*a1*a1Yup, 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.
does this table summarize it well?
@woile see also conventional-commits/conventionalcommits.org#398 (comment).
A note to avoid duplication — we’re working on a change for this issue.
Reacted by Santiago Fraire WillemoesTriage from #1964: Same root behaviour as #415 — once you're on a prerelease, every
cz bump --prerelease betaissues a new prerelease bump regardless of commit content, while a non-prerelease starting point requires bumpable commits. This is currently a design choice. If we want to change it, that decision should probably happen in #415 / a dedicated discussion.Verification update (re #1964)
Reproduced against current master (4.15.1):
Starting from
v1.2.1:fix: a fix+cz bump --prerelease beta --yes→ bumps tov1.2.2b0(increment detected: PATCH) ✓- Then
build: tweak(non-bumpable) +cz bump --prerelease beta --yes→ bumps tov1.2.2b1✗
Verdict: STILL VALID — once on a prerelease, every
cz bump --prereleaseissues another prerelease bump regardless of whether commits are bump-eligible.The asymmetry: from a non-prerelease starting point,
--prereleaserequires eligible commits (#415 — exits withNO_COMMITS_FOUND). From a prerelease starting point, it bumps unconditionally.In
commitizen/commands/bump.py:_resolve_increment_and_new_version, the check at lines 216-225 only raisesNoCommitsFoundErrorwhennot current_version.is_prerelease. So once on a prerelease, no commit-eligibility check is performed.Possible behavior change: even when on a prerelease, only bump if there's at least one commit since the last release that would otherwise trigger an increment (or that the user explicitly opted into via
--increment/--allow-no-commit). This would makecz bump --prerelease betaa useful tool for "release if there's something releasable" automation.Worth a design discussion before changing — could break someone's release pipeline that relies on the current behavior.
Description
Running
$ cz bump --prerelease betawhen the current version is a previous pre-release bumps the version even when there are no commits that would require it, e.g. onlybuild/cicommits.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.2b0as expected$ git commit -m "build: Local devel change not requiring release"$ cz bump --prerelease beta-> Bumps unexpectedly tov0.0.2b1Current behavior
Maintainers can't use
$ cz bumpas 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