[yegortimoshenko]

> When we launched Babel 6, we made an API change that we had planned for awhile. We moved from having an implicit (“works out of the box”) behavior to an explicit (“will work for everyone”) behavior.

Just like Rich Hickey said in his last talk (see https://news.ycombinator.com/item?id=13085952), breaking changes are broken. For greater good or not, it's no surprise people complain when you break their code/workflow.

> I want to talk to you about an article that was written the other day titled “Angular 2 is terrible”. For starters, that title alone is an attack on the maintainers. Surely the author wants a set of problems addressed. But why should the maintainers want to even click on that link, let alone try to address the problems?

I too think that Angular 2 is terrible. It is not an attack on the maintainers, it is just a piece of (IMO) bad technology with maintainers feeling attached to it.

It is a very crucial skill in life to be able to withstand critique and take it to your advantage. There is a lot of usually unnoticed utility hidden in critique, waiting for someone to reap its benefits.

[thejameskyle]

People keep assuming I have something against sharing criticism or frustration. I never said that. I explicitly said that's not what I'm trying to say.

I'm saying that when someone does it in a way that is in pure unadulterated anger that the community should not reward them for it. It's unhealthy for everyone.

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