Skip to content
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

Bump increments to new pre-release version from pre-release version when it wouldn't from final version #688

Open
rpatterson opened this issue Mar 16, 2023 · 9 comments

Comments

@rpatterson
Copy link

rpatterson commented Mar 16, 2023

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. only build/ci commits.

Steps to reproduce

  1. Start with a final version, e.g. v0.0.1
  2. $ git commit -m "ci: CI-specific change not requiring release"
  3. $ cz bump --prerelease beta -> Refuses to bump the version as expected
  4. $ git commit -m "fix: Prospective fix requiring beta testing"
  5. $ cz bump --prerelease beta -> Bumps to v0.0.2b0 as expected
  6. $ git commit -m "build: Local devel change not requiring release"
  7. $ cz bump --prerelease beta -> Bumps unexpectedly to v0.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 making build: .../ci: ... changes while features are in beta testing, this behavior results in a lot of noisy, meaningless v#.#.#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
@jenstroeger
Copy link
Contributor

jenstroeger commented May 15, 2023

I just noticed the same behavior: with the --prerelease switch 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 to 0.1.1a0 which is ok
  • git commit --allow-empty --message 'feat: a feature'
  • cz bump --prerelease alpha → bumps to 0.1.1a1 which is incorrect, I would have expected 0.2.0a0 and we lost the “feature” bump
  • git commit --allow-empty --message 'chore: a chore'
  • cz bump --prerelease alpha → bumps to 0.1.1a2 which 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 to 0.1.1a3 which is incorrect, I would have expected 1.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 cz to implement that soon?

@woile
Copy link
Member

woile commented May 16, 2023

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.1a1 to 0.2.0a0 to 1.0.0a0 to 2.0.0a0 without 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 like cz bump --increment-only in case someone wants to automate based on the commits, and from there: cz bump --increment $(cz bump --increment-only) --prerelease alpha?

@rpatterson
Copy link
Author

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.0 final release means a feature was released, right? If then a bug fix is released as a pre-release, it should be v0.1.1a1 because if it checks out and goes to final release, then that would be v0.1.1, right? If before v0.1.1a1 makes it to final release, someone merges a feature, then a pre-release for that should not be v0.1.1a2 because when it does make it to final release it should not be v0.1.1. When it gets to final release it should be v0.2.0, hence a pre-release containing that feature should be v0.2.0a0. If then, however someone merges another feature and a final v0.2.0 hasn't been released yet, then the pre-release for that second feature should be v0.2.0a1, not v0.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.

@jenstroeger
Copy link
Contributor

jenstroeger commented May 18, 2023

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: and feat: and chore!: commits can cz bump the next version correctly?

Currently it doesn’t, see above.

@rpatterson
Copy link
Author

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.

@woile
Copy link
Member

woile commented May 20, 2023

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 *a1 0.2.0a0 0.2.0a0 or 1.0.0a0 (depending on major_version_zero)
0.1.0a0 *a1 *a1 0.2.0a0 or 1.0.0a0 (depending on major_version_zero)
1.0.0a0 *a1 *a1 *a1

@rpatterson
Copy link
Author

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.

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 *a1 0.2.0a0 0.2.0a0 or 1.0.0a0 (depending on major_version_zero)
0.1.0a0 *a1 *a1 0.2.0a0 or 1.0.0a0 (depending on major_version_zero)
1.0.0a0 *a1 *a1 *a1

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.

@jenstroeger
Copy link
Contributor

jenstroeger commented May 21, 2023

does this table summarize it well?

@woile see also conventional-commits/conventionalcommits.org#398 (comment).

@jenstroeger
Copy link
Contributor

A note to avoid duplication — we’re working on a change for this issue.

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

No branches or pull requests

3 participants