> 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 bug

> 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. 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.