Conventional Commits

[doxxx]

May I suggest Conventional Commits to make your changelogs more readable?

[seriouz]

I had the same thought after seeing the generated change log.
The important part is to format the PR commit messages during the squash accordingly.

[Regenhardt]

Any idea if the current release action properly handles conventional commits?

[Regenhardt]

Oh, was totally looking at the wrong workflow step there. So I just push a new tag and the workflow should do its thing, right?

[seriouz]

Yes. We'll see how good the multi line merged messages will appear. Tag the latest commit in the main branch with v1.2.0.

[Regenhardt]

I pushed the new tag, but I can't see a workflow running or a new Release. Do I have to create the release via Github? I expected the pipeline to do that.

[seriouz]

It should run automatically when pushing a Git tag. Try to remove the v1.2.0 and re-push it.

[Regenhardt]

This one worked, changelog looks good, thanks✌.

[Regenhardt]

Looks like a squashed commit will only appear as a single change in the changelog, even if there were multiple commits with conventional commit messages squashed into it. Which kinda makes sense as that is a purely github thing to do and conventional commits aren't modelled after github. I guess we have to choose between squashing into a single change or rebase-merge if we want to keep the changes separate.

[doxxx]

Yes, that's what I would expect. One commit -> one change as far as conventional commits is concerned. If you're merging a branch into main that has multiple distinct commits/changes, it would be best to rebase it onto main and then do a fast-forward merge so that each of those distinct changes appear as distinct commits on main.