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

Any conventional commit results in a PATCH version, not just fix #1020

Open
1 task done
S-Scholz opened this issue Jan 23, 2025 · 1 comment
Open
1 task done

Any conventional commit results in a PATCH version, not just fix #1020

S-Scholz opened this issue Jan 23, 2025 · 1 comment
Assignees
Labels
bug Something isn't working

Comments

@S-Scholz
Copy link

Is there an existing issue for this?

  • I have searched the existing issues

Description of the bug

First of: thanks for this project. When I tried to integrate it to calculate the next release version based on the commits I ran into the following problem:

Adding any conventional commit to the history results in a patch increase of the version, when git-cliff ---bump is used.

  • Is this intended?
  • If that is so, can this be configured in anyway?

Steps To Reproduce

The following history works as expected, and produces v0.1.0 via git-cliff --bumped-version

8e33455 (HEAD -> master) another commit
f1990f3 feat: a commit
306b48a (tag: v0.0.0) init commit

Adding the new tag and a commit that is not fix|feat:

da805b7 (HEAD -> master) ci: should not create a patch
8e33455 (tag: v0.1.0) another commit
f1990f3 feat: a commit
306b48a (tag: v0.0.0) init commit

Results in version of v0.1.1. Same behaviour for e.g. docs: add readme.

Additionally, adding the following settings to the default cliff.toml:

...
[bump]
custom_major_increment_regex = "major"
custom_minor_increment_regex = "minor|more"

Does not affect this behaviour.

Expected behavior

As per the documentation (https://git-cliff.org/docs/usage/bump-version)

"fix:" -> increments PATCH
"feat:" -> increments MINOR
"scope!" (breaking changes) -> increments MAJOR

I would expect that, a patch version should only be created if there is a fix: ... commit in the unreleased history. The following history should not create a patch increase.

da805b7 (HEAD -> master) ci: should not create a patch
8e33455 (tag: v0.1.0) another commit
f1990f3 feat: a commit
306b48a (tag: v0.0.0) init commit

However, a new patch version is created:

$ git cliff --bump --context | jq '.[0].version'
"v0.1.1"

Screenshots / Logs

No response

Software information

  • Operating system: debian
  • Project version: 2.7.0 (pre-compiled)

Additional context

cliff.toml:

[changelog]
header = """
# Changelog\n
All notable changes to this project will be documented in this file.\n
"""
body = """
{% if version %}\
    ## [{{ version | trim_start_matches(pat="v") }}] - {{ timestamp | date(format="%Y-%m-%d") }}
{% else %}\
    ## [unreleased]
{% endif %}\
{% for group, commits in commits | group_by(attribute="group") %}
    ### {{ group | striptags | trim | upper_first }}
    {% for commit in commits %}
        - {% if commit.scope %}*({{ commit.scope }})* {% endif %}\
            {% if commit.breaking %}[**breaking**] {% endif %}\
            {{ commit.message | upper_first }}\
    {% endfor %}
{% endfor %}\n
"""
footer = """
<!-- generated by git-cliff -->
"""
trim = true
postprocessors = [ ]

[git]
conventional_commits = true
filter_unconventional = true
split_commits = false
filter_commits = false
topo_order = false
sort_commits = "oldest"

[bump]
custom_major_increment_regex = "major"
custom_minor_increment_regex = "minor|more"
@S-Scholz S-Scholz added the bug Something isn't working label Jan 23, 2025
Copy link

welcome bot commented Jan 23, 2025

Thanks for opening your first issue at git-cliff! Be sure to follow the issue template! ⛰️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants