That's what I do, yes. What I tried to explain is how library devs generally update versions.
> Yes, but if it's a minor version change then, as a developer, I also want to review the changelog for new features I should consider whether we should add backlog items for refactoring to take advantage of, while a patch doesn't create that need
This sounds like a good argument; although in my professional experience I found that 1) I need to re-test anyway 2) I need to read the change description anyway (as bugfixes most of the time mean behavioral changes, so I want to understand why the patch was necessary).
So overall I understand the theoretical argument behind semver, but I still don't see a very strong argument behind it. At least not as strong argument as popular semver has become.
Collecting evidence for bold claim is left as an exercise to the reader.
Yes, it does.
> Both in the case of a minor or patch version change the client should be able to upgrade to the latest version.
Yes, but if it's a minor version change then, as a developer, I also want to review the changelog for new features I should consider whether we should add backlog items for refactoring to take advantage of, while a patch doesn't create that need. There is more space for SemVer-aware tooling than “is this safe to update”, though that's obviously the most important single piece of information.
> The real reason for minor and patch versions is that libraries actually don't follow semver, and patch version change means 'small change, don't worry about re-testing'
No, you always worry about retesting because SemVer is a statement of API intent, but does not include a guarantee against bugs, including new or modified bugs.