Support separating breaking changes from other changes

[bal-stan]

Is there an existing issue or pull request for this?

• I have searched the existing issues and pull requests

Feature description

I want to separate the breaking changes in the changelog from other changes, so that users can easily find them.

For example a changelog should look something like:

## Breaking Changes

### Fixes:

- Change 1
- Change 3
- Scope: Change 4

## Non-Breaking Changes

### Fixes:

- Change 2
- Scope: Change 5

### Other (commits that do not follow conventional-commits format

- Change 6
- Change 7

I've tried to implement this but filtering is currently impossible because if a commit does not follow the conventional-commits format its breaking field is missing from the context (or maybe its null?), instead of being false.

According to the Tera filter docs a value cannot be filtered if it is null (I suppose missing == null). Thus these are always dropped when filtering.

Ther result of this is that I can filter by which commits are breaking (filter(attribute='breaking', value=true)), but I cannot filter by which commits are not breaking, because their breaking field might be false, null or I suppose even missing.

Desired solution

Either a custom filter that will allow this, or the breaking field to always be set to false unless conventional commits says it must be true.

Alternatives considered

Do something like:

...
# {{ group }}
{% if commit.breaking %}{% continue %}{% endif %}
....

But that will produce an empty group if all commits in a given group are breaking.

Additional context

No response

[orhun]

Hello, thanks for reporting! 👋🏼

Just by looking at the alternative provided, it seems like the easiest way. You can avoid creating an empty group by updating it like:

{% if commit.breaking %}{% continue %}{% endif %}
# {{ group }}

And the reverse of that would be {% if commit.breaking == false %}{% continue %}{% endif %}.

because their breaking field might be false, null or I suppose even missing.

Now when it comes to the actual problem, which is breaking field not existing or set to null. It happens because we cannot detect if a commit is breaking or not without parsing it. And I think setting it to false in those cases would be misleading.

Btw it would really help if you can provide minimal Git commands for the desired changelog, something like:

git commit --allow-empty -m "Initial commit"
git commit --allow-empty -m "feat: add feature 1"
git commit --allow-empty -m "fix: fix feature 1"
git tag v0.1.0
git commit --allow-empty -m "feat(gui)!: add feature 2"
git commit --allow-empty -m "fix(gui): fix feature 2"
git tag v0.2.0
git commit --allow-empty -m "test: add tests"

Along with what you want to see in the changelog :)

[bal-stan]

Thanks for the quick response.

Just by looking at the alternative provided, it seems like the easiest way. You can avoid creating an empty group by updating it like

Hmm, I think I tried this but it didn't work quite right. I can try again.

Regardless, based on the commits you provided, I would expect to see something like this in the changelog:

# Changelog

All notable changes will be documented in this file.

## [unreleased]

### Tests

- Add tests

## [0.2.0](https://github.com/.../v0.1.0..v0.2.0)

### Breaking Changes

#### Features

##### gui

- Add feature 2

### Bug Fixes

#### gui

- Fix feature 2

## 0.1.0

### Bug Fixes

- Fix feature 1

### Features

- Add feature 1

### Other

- Initial commit