[yegortimoshenko]

I don't think you understand. The critique itself, whether constructive or not, is something to learn from.

Just like breaking changes in Babel 6. There is a lesson waiting to be learnt, namely, don't make breaking changes to existing software.

As a matter of fact, I honestly don't understand why you take it so personally. Sometimes I do stupid things and people call me an idiot, and it's helpful to know that. Sometimes it gives me a perspective I haven't thought of.

Look at how Theo de Raadt and Linus Torvalds manage their projects. It is kind of the same.

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

[jdd]

I dig Babel 6. I'm glad they took the major bump, which allows breaking changes, to improve things.

The major bump means it's opt-in, so folks can continue to use the older version without breaking their workflow.