[Klathmon]

If I can ask, what's your alternative to breaking changes?

Most of the time when I see a large library make breaking changes, it's to solve a problem which can't realistically be "fixed" without breaking changes.

And even if they can provide a "shim" to allow people to use the old way of doing things, people see that the same as they see maintaining an old release. That you need to upgrade to the latest version or you'll be left behind.

I'm not trying to put words in your mouth, but it seems like the only options left are to "never improve" or "get it right the first time". And obviously the latter isn't possible pretty much at all.

[yegortimoshenko]

I'd argue that most breaking changes are not about fixing problems. They are about API consistency and taste, like Babel 6 mentioned above.

If problem is a bug that people might rely upon, I don't mind fixing it. If problem is fundamental design-wise, however, the right way is to create a new library.

There are a lot of designs that never break anything (or at least try hard not to): Linux, macOS, Erlang, Java, Clojure, x86 instruction set, life on earth, and they all improve over time. And they obviously didn't get everything right the first time.