Sometimes you need to break backwards compatibility to fix a security issue or implement a new, desired feature. Most often the breakage is small, but it's still nice to know as a library user when the build may break.

Yes, try to avoid breaking backwards compatibility, but have some mechanism to handle the rare case when you do need to break guarantees.

Most of the libraries I use that follow semver rarely break backwards compatibility, and it's still helpful to use semver to note bugfixes vs new features. New features can be a liability and introduce bugs, bugfixes are frequently quite safe, so it lets me know how much effort I should expect to spend testing when pulling in a new version. When I'm close to a release, I'll avoid new feature releases, but probably pull in bugfix releases.

Your reply feels unnecessarily confrontational / aggressive, but I’ll respond anyway.

> Everyone else just maintains backwards compatibility.

Name one piece of software of substantive size and with a history longer than a couple years, which never had a backwards compatibility break ever? Just in case you can name one, then name two instead. Contrary to your statement, 99.99999% of software has a backwards incompatible change at some point. What’s a good way to indicate that to your end users? Semantic versioning.

> Nobody asked you to "improve" you library by breaking it.

So if a major bug is found after release, one should never fix it? Fixing a bug could easily lead to a backwards incompatible break, if nothing else because someone was depending on that buggy behavior.