Hi @JeromeCheviet,

I'm glad you noticed and appreciated the updates I've made to the default changelog, but I'm sorry that something changed to non-desired behavior for you.

Without a in-depth analysis between your commit tree and the resulting changelog, I am limited to only guessing what likely is the cause. Since you were able to narrow it to 9.12.0 then I found that this release notes entry is likely the change that is mis-understood.

### Bug Fixes

- changelog: ignore commit exclusion when a commit causes a version bump ([e8f886e](https://github.com/python-semantic-release/python-semantic-release/commit/e8f886ef2abe8ceaea0a24a0112b92a167abd6a9))

When you open the commit link, you will see the following comment in the code.

# Skip excluded commits except for any commit causing a version bump
# Reasoning: if a commit causes a version bump, and no other commits
# are included, then the changelog will be empty. Even if ther was other
# commits included, the true reason for a version bump would be missing.

I see that this is in fact the point of confusion, because after looking at your configuration you have all those tags that you want to ignore as commits that cause a version bump.

Maybe it would make more sense for PSR to re-evaluate all the parsed commit objects relative to a single version to be ok to exclude commits that are not the single cause of the bump. If you find that all your occurrences are groups of commits that all cause a patch version. However, if all the commits are the same bump and they all are excluded then we have the same problem detailed above and I would throw out the re-evaluation result.

Just to offer a recommendation to your configuration, it is my opinion that you should only trigger a release for the following for most types of projects:

minor_tags = ["feat"]
patch_tags = ["fix", "perf"]

My rationale is based on the fact that all other tags essentially do not change the functionality of the code that the user receives. You have to ask, Why would you release it (if he/she is using dependabot or something similar) which ends up notifying the end user to update if it doesn't actually improve their runtime use? Updating and upgrading is a cumbersome step for most who take the due diligence to validate their updates so it is more considerate of the developer to not release for all change types. This especially applies to the commit type of chore, style, and refactor. chore is for things irrelevant to the runtime code and style doesn't change the use or performance of code.

refactor might seem a bit odd as it does change the runtime code the user is using but generally the changes that actually matter to the user is the refactors that increase performance otherwise labeled as perf.

ci changes generally have 0 effect on the users runtime application unless it changes the build somehow and at that point you should consider if they actually need the change right away or can it wait to the next feat, fix, perf update.

build is the one that I am the most indecisive with as many times it can impact the user's runtime environment. I personally have settled on that build(deps) is one that should cause a release, because it is immediate that you will want to immediately provide the user an update when one of your runtime dependencies has a security vulnerability that was just patched. Almost all other build related changes can wait until the next feat, fix, perf update because they don't actually change the runtime. In a future version of PSR, I plan to provide the ability to define the pairing of commit type to scope that together define or not define a version bump to help support this ambiguity.

As for revert, its hard to say. PSR currently does not support revert and I personally never use it because I don't have a need to. When future PSR implements it, it will be difficult to define as it will need to be evaluated per the latest set of unreleased commits. If it has a subject match than it just eliminates both of the unreleased commits, and no version change is detected. However if its match was already released in a previous version, now it would trigger based on whatever commit type was in the revert subject that it changed.

All in all, as long as you have all the alternates in the allowed_tags list (like you do for docs), then PSR will not throw an error on parsing but also will not increase the version bump value.

Hello,

Thank you for this very interesting feedback. I will need to study all of this.

As requested in your first message, here is an extract from the commits and the changelog on a test project:

git log --oneline

9591485 (HEAD -> main) docs: @DTK1-3136 generate commit for test psr
9b5cea7 perf: @DTK1-3136 generate commit for test psr
0cf6fe3 build: @DTK1-3136 generate commit for test psr
7489e59 style: @DTK1-3136 generate commit for test psr
1f3f493 perf: @DTK1-3136 generate commit for test psr
e1049ca refactor: @DTK1-3136 generate commit for test psr
954c2cc style: @DTK1-3136 generate commit for test psr
f8fb500 ci: @DTK1-3136 generate commit for test psr
8ca2c9d test: @DTK1-3136 generate commit for test psr
f7d3526 test: @DTK1-3136 generate commit for test psr
2220f5e (tag: 1.1.0-beta.1) test: @DTK1-3136 generate commit for test psr
c264a15 test: @DTK1-3136 generate commit for test psr

more CHANGELOG.md


## v1.1.0-beta.2 (2025-05-19)

### Build System

* build: @DTK1-3136 generate commit for test psr ([`0cf6fe3`](https://gitlab.com))

### Code Style

* style: @DTK1-3136 generate commit for test psr ([`7489e59`](https://gitlab.com))

* style: @DTK1-3136 generate commit for test psr ([`954c2cc`](https://gitlab.com))

### Continuous Integration

* ci: @DTK1-3136 generate commit for test psr ([`f8fb500`](https://gitlab.com))

### Performance Improvements

* perf: @DTK1-3136 generate commit for test psr ([`9b5cea7`](https://gitlab.com))

* perf: @DTK1-3136 generate commit for test psr ([`1f3f493`](https://gitlab.com))

### Refactoring

* refactor: @DTK1-3136 generate commit for test psr ([`e1049ca`](https://gitlab.com))

We see that the "docs" that I commit are not in the CHANGELOG.md file.

Thanks! It confirms what I thought once I saw your config about half way through my first answer. Hopefully my insight was helpful. I will consider a re-eval of the set of commits as I didn't previously.