Changelog conflicts

[ashiazed]

Since the repo has automated changelog checks in the CI, are you open to using something that minimizes conflicts in CHANGELOG.md?

The simplest I've found is to have a changelog/unreleased folder with yml files like this:

---
message: Blah blah this is the changelog message
category: Added

And every PR would just add a new file. I believe the CI action (action-changelog-reminder) supports this as well.

We'd then need a simple script to aggregate the CHANGELOG.md message for the release commit and delete the old yaml files.

Just thought I'd ask.

[timjklein36]

Just for my clarity, are the conflicts you refer to here related to multiple new changes being merged into the main branch and each subsequent merge containing a conflict in the same section of the CHANGELOG.md?

In those cases, requiring a pull of the main branch back into the PR branch to resolve the conflict prior to its own merge?

E.g.:

1. PR for Feature A (feature/a branch) created with an addition under Added in CHANGELOG.md
2. PR for Feature B (feature/b branch) created with an addition under Added in CHANGELOG.md
3. PR for Feature A is merged (feature/a branch merged into main)
4. PR for Feature B now requires pulling in main to resolve the conflict in CHANGELOG.md

In most cases, I feel like git handles these "conflicts" automatically, since they are both added lines, but maybe I am misunderstanding your example.

[timjklein36]

For extra context, this project uses the Keep a Changelog format for simplicity and to make it easy for on-boarding new contributors.

If a new format/system were to be put in place, it would need to be documented.

[ashiazed]

I guess it's more of an issue with outstanding PRs and new commits.
As an example, I have a few PRs out for review.
For the first one, after someone else merged a PR I got a conflict, and then needed to update my branch (I rebased) - which then removed the approval and I had to wait for CI to be run again and am waiting for re-approval.

I was worried that each one of the other PRs will need the same flow. Approve, merge to main branch, update other PR with new merge/rebase, go through reapproval process.
Maybe I am misunderstanding the flow here?

[ashiazed]

So less about the dealing with the conflict (which git can handle of course) but removing the need for dealing with the conflict in the first place.

There is definitely a balance of the benefit of a more obvious entry on CHANGELOG.md with some conflicts, or less conflicts with a custom changelog format/folder.