This is precisely why I started https://keepachangelog.com/ many years ago. Release convenience shouldn't come at the cost of properly communicating about notable changes for software users (whether developers themselves, or software consumers).
Instinctively, developers reach for automation to solve this problem but this is an editorial problem for most software. Code changes very rarely map to notable changes for your intended audience. Even with rigid system like conventional commits, you can't entirely automate proper human-focused changelogs and release notes.
You're going to have to clean things up and editorialize if you really care for your software users to understand what notable changes are included in a given version release.
If you can't think of any, maybe you're releasing too often. If it's impossible to tell things apart because there are so many changes as another commenter pointed out, I think you have a way bigger problem.
Instinctively, developers reach for automation to solve this problem but this is an editorial problem for most software. Code changes very rarely map to notable changes for your intended audience. Even with rigid system like conventional commits, you can't entirely automate proper human-focused changelogs and release notes.
You're going to have to clean things up and editorialize if you really care for your software users to understand what notable changes are included in a given version release.
If you can't think of any, maybe you're releasing too often. If it's impossible to tell things apart because there are so many changes as another commenter pointed out, I think you have a way bigger problem.