For reasons beyond me, I've been looking through the CHANGELOG.md and I'm seeing a lot of empty versions. Looking at v2.111.14 in particular you can see there's something in the commit diff that seams relevant.
I've traced it back to the change log generation script, which contains the following relevant bits:
# If the subject contains "Merge pull request #xxxxx" then it is deemed a pull request
if pull_request=$( grep -Eo "Merge pull request #[[:digit:]]+" <<< "$subject" );then
# Process merge commits from PRs
...
fi
if grep -qEo "[[:alpha:]]+:" <<< "$subject"; then
# Process conventional commits
...
fiIt seams to me that the implied standard of this tooling is that you have to either:
a) Use normal merge commits instead of squash commits, or
b) Use the standard <type>: description commit naming structure for the squash commit.
So my assumption is that you're doing (b) without the naming structured and that's making the change logs less valuable.
For reasons beyond me, I've been looking through the CHANGELOG.md and I'm seeing a lot of empty versions. Looking at v2.111.14 in particular you can see there's something in the commit diff that seams relevant.
I've traced it back to the change log generation script, which contains the following relevant bits:
It seams to me that the implied standard of this tooling is that you have to either:
a) Use normal merge commits instead of squash commits, or
b) Use the standard
<type>: descriptioncommit naming structure for the squash commit.So my assumption is that you're doing (b) without the naming structured and that's making the change logs less valuable.