Hacker News Reader

Comment by one_off_comment | Hacker News Reader

I'm not tedajax, but my guess as to what they meant is that it's an abysmal mindset to think that making a breaking change to an API means that the previous API was wrong. And I tend to agree. Needs and assumptions change and sometimes that means your API needs to adapt in a backwards-incompatible way. That doesn't mean your previous API was wrong for what it was built for. It just means it's wrong for the new expectations.

I agree with tedajax that looking at any breaking changes as a failure is a pessimistic, fatalistic, harmful viewpoint... assuming that's what tedajax had in mind.

View on HN

Yeah that's pretty much what I had in mind.

I'd add further that more than likely once your API became something usable new use-cases and ideas came up. I wouldn't call major version numbers "failures" but "evolutions".

The context of your project changing over the years requiring breaking API changes is good and healthy.

“Fail” is an overloaded word.

The new version fails under the previous versions API. That doesn’t mean that there is anything wrong with either old or new release or API, just that there are breaking API changes and it should not be considered a drop-in upgrade before properly reading through release notes.

There’s no implication of failure. Like you say, it happens.

The tweet literally says:

>The thing about semver major version numbers are that they don't mean new stuff, they're a permanent reminder of how many times you got the API wrong.

The API was wrong. If you were an omniscient being with complete understanding of the future when you designed it, you would have known that.

Not necessarily. See my comment above. Needs change. Breaking an API can be reasonable to accommodate for that. It does not mean the past decision was incorrect even with current knowledge.

That's my point: "Needs change". If you were a supernatural omniscient being with full knowledge of all possible pasts and futures you would have predicted that need.

Since none of us are omniscient it's OK for us not to build the perfect API the first time round!

Maybe I’m building my API for the users and use-cases for today and next year, intentionally not accommodating for those in 10 years. Those will be addressed in an upcoming breaking release at some point until then. This can be a sane decision even if you have full knowledge of what’s coming.

Reply on news.ycombinator.com