[MikeTaylor]

I did wonder how much to soften this message, because yes, of course, there really ARE times when a breaking change is necessary. But I think those account for maybe 1% of the major releases we see these days. The rest are down to laziness, carelessness, or just not having thought about it at all.

[TillE]

This is an extremely uncharitable way to characterize how our understanding of a problem, our requirements, etc evolve over time and with feedback from users.

Making a good API is really hard. I think there's plenty of room for discussion about how we should break things, but "just do it right the first time" is not realistic.

[MikeTaylor]

And yet, it's what a lot of old-timey software engineers consistently did. Yes, we work in a more complex ecosystem than they did, but I can't shake my sense that 90% of the reason is that they held themselves to a higher standard. Heck, they still do in the Go community, where major versions are still a big deal.