5 ms·

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

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.

simonw 5y ago
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.
- 3np 5y ago
  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.
  - simonw 5y ago
    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!
    - 3np 5y ago
      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.
3np 5y ago
“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.
- Stampo00 5y ago
  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.
tedajax 5y ago
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.

simonw 5y ago

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.

3np 5y ago
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.
- simonw 5y ago
  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!
  - 3np 5y ago
    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.

3np 5y ago

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

Stampo00 5y ago
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.

tedajax 5y ago

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.