Semantic Versioning is a terrible mistake

reprog.wordpress.com

4 points·MikeTaylor··4 comments

I'm amenable to the idea of not making breaking changes if you can help it.

But...

> To say it another way: If you need to make a breaking change to your API, it means you screwed up. Don’t screw up.

I'm skeptical that we can always predict the future well enough to get an API perfect from the beginning.

Sometimes the best we can do is do the best we can, learn, and do better.

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.

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.

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.

Reply on news.ycombinator.com