Allow bump calculate the next version from git log

[pablodgonzalez]

Description

Currently, when skip commits and no using tags at all (in my use case, I bump the version with each commit) always get a MAYOR bump, but my commit is not a BREAKING CHANGES.

Possible Solution

When sip using tags at all, use the git log to read the commit messages and calculate the next version in bump

Additional context

No response

Additional context

No response

[Lee-W]

Hi @pablodgonzalez , I don't quite understand. Could you please provide an example for helping us understand? Thanks!

[pablodgonzalez]

Sure, My team use commitizen for the wizard to prepare the commit message, to check the commit message and to do the bump version.
But for the last one we use pre-commit to

- repo: local
    hooks:
      - id: cz-bump
        name: "📝 commitizen · Bump version"
        entry: bash -c 'cz bump --increment PATCH --files-only --yes && git add .cz.toml CHANGELOG.md main/settings/base.py'
        language: system
        pass_filenames: false
        always_run: true
        stages:
          - commit-msg

rigth now, we force a PATCH bump, because the bump use the tag version to check the last version and calculate what kind of increment to do.
Since we do not use tags, instead would like to use just the kind on commit (breaking change, feat, fix, etc) but those only work when tagging
Of course we are a little taem so a few of dev work over this repo.

[woile]

Can you share your configuration? Have you tried building your own version provider?

[pablodgonzalez]

this is our configuration, I didn't tried with a version provider

[tool.commitizen]
name = "cz_conventional_commits"
version = "1.0.2"
version_provider = "commitizen"
update_changelog_on_bump = true
changelog_incremental = true
tag_format = ""
version_files = [
  "main/settings/base.py"
]
search = "VERSION = \"v{version} - VERSION DEV\""
replace = "VERSION = \"v{new_version} - VERSION DEV\""

[woile]

can you share the list of commits?

I assume you must have a BREAKING CHANGE somewhere or a !. I think there's no way to avoid it because if you don't use tags, then in order to calculate the next version bump, commitizen will scan all the commits, it has no way to know when the last commit was.

[pablodgonzalez]

Exactly, that's is the reason my proposal is get the last log (or las commit) in terms of we are a little team so the idea is the devs update de versión based in their works, an any issue with the versioning is solved manually (we always make a rebase before make a PR) so, we control the flow of commit over the integration branch. In summary, I want to the devs can to do a solid commit message, and update the version based in the message of those commits. each time they make a commit. the versión conflicts can solve easy while do the rebase.
Maybe this a particular use case and doesn't have sense make this feature

[woile]

I don't see this feature moving forward.

Observing the latest commit to increase the version and avoid tagging

It seems very very niche for us to maintain. Unless we can really provide some valid points, that can be generally applicable to many other teams. What do the other maintainers think? @Lee-W @noirbizarre ?

For me there are a bunch of questions to be answered:

• why not use tags?
• what do the developers use the version that they create in their development branch for?
• what's the point of having a bump per branch? if you publish those pypi (or another), later you may have conflicts.
• wouldn't developers have endless rebase conflicts?

[Lee-W]

It seems very very niche for us to maintain.

Agree with it. But, if we can bump based on a certain commit instead of the last commit, would it be helpful 🤔 If we could use tag to track the latest bumped commit, we probably could use SHA as well. Not using tag is a feature we got asked occasionally, but never got a good proposal on the "how". Maybe storing SHA is one way?