This is just a small suggestion regarding the release notifications.
While I totally understand that auto-generating those saves maintainer time, it also means the release notifications as they are now, are next to useless and wastes maintainer time on the other side.
It is my firm believe that changelogs are for humans and all CI/test/doc updates which do not impact end-users should just be grouped under a single "Various housekeeping, including improvements to the tests and documentation." entry in a changelog.
If, and only if, a dependabot update is relevant for end-users, it can be mentioned in the changelog, but only with a single entry per dependency.
Example from the 2.49.0 release (and I'm pretty sure this isn't even relevant for end-users):
Instead of having 9(!!) "composer(deps-dev): Bump ergebnis/php-cs-fixer-config from by @dependabot[bot] in #..." entries in the release notification, one would have sufficed and would have made the release notification infinitely more readable:
- Dependency update: ergebnis/php-cs-fixer-config from 6.53.0 to 6.58.2 by @dependabot[bot]
Even grouping the changelog entries into the typical semver "Added'/"Changed"/"Removed"/"Fixed"/"Maintenance" categories (where everything in "maintenance" can be ignored by non-contributors) would already help.
The problem with the release notifications as they are now, is that it takes every single person trying to find out what has changed five minutes to figure out what the relevant changes are, which is five minutes wasted per project depending on this package.
I hope you'll at least consider my request.
Just as an example - this is what the changelog for the 2.49.0 release could have looked like and it would still have contained all the relevant information about the release:
## Changed
* Update schema.json by @ergebnis-bot in #1507
* Update composer/composer by @localheinz in #1553
* Various housekeeping.
## Fixed
* Remove infection/infection by @localheinz in #1552
(and the entry regarding #1552 could probably still be folded into the "housekeeping" entry too)
This is just a small suggestion regarding the release notifications.
While I totally understand that auto-generating those saves maintainer time, it also means the release notifications as they are now, are next to useless and wastes maintainer time on the other side.
It is my firm believe that changelogs are for humans and all CI/test/doc updates which do not impact end-users should just be grouped under a single "Various housekeeping, including improvements to the tests and documentation." entry in a changelog.
If, and only if, a dependabot update is relevant for end-users, it can be mentioned in the changelog, but only with a single entry per dependency.
Example from the 2.49.0 release (and I'm pretty sure this isn't even relevant for end-users):
Instead of having 9(!!) "composer(deps-dev): Bump ergebnis/php-cs-fixer-config from by @dependabot[bot] in #..." entries in the release notification, one would have sufficed and would have made the release notification infinitely more readable:
Even grouping the changelog entries into the typical semver "Added'/"Changed"/"Removed"/"Fixed"/"Maintenance" categories (where everything in "maintenance" can be ignored by non-contributors) would already help.
The problem with the release notifications as they are now, is that it takes every single person trying to find out what has changed five minutes to figure out what the relevant changes are, which is five minutes wasted per project depending on this package.
I hope you'll at least consider my request.
Just as an example - this is what the changelog for the 2.49.0 release could have looked like and it would still have contained all the relevant information about the release:
(and the entry regarding #1552 could probably still be folded into the "housekeeping" entry too)