4 ms·

The introductory paragraphs and the proposed Alternative are completely disjointed. The stated problems are caused by breaking API changes. The author says it

by vemv 6y ago

The introductory paragraphs and the proposed Alternative are completely disjointed. The stated problems are caused by breaking API changes. The author says it clearly: don't break your API. Now, how does a different version naming convention change anything? You still have breaking changes, just with a different name. And I'm not sure at all that dates make it any easier to spot breaking changes. There's this very illustrative talk explaining why breaking API changes are such a bad thing. https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/Spec_ulation.md https://github.com/matthiasn/talk-transcripts/blob/master/Hi...

betenoire 6y ago
nah the author addresses this: > Make a new thing, name it something else, figure out the migration that makes sense for you and your users. If you follow that advice, you don't have a broken API and the rest still follows.
- vemv 6y ago
  It's also possible to follow the alternative and still keep breaking APIs. It's much more effective to focus on a single thing (breaking change rejection) than to pretend that one thing can be magically accomplished through another.
  - betenoire 6y ago
    yeah, the scheme doesn't somehow prevent you from breaking your API. that's still on us :)
- pornel 6y ago
  That doesn't fix anything. • Most often people break semver by accident, so they wouldn't know when a release should have been "a new thing" instead. You can't replace QA with a versioning scheme. • Hyrum's Law means you can't really change anything without risk of breaking someone somewhere. It's hard to know what can you change without breaking someone. If you try to never break anything, it leads to absurd trade-offs (every release becomes a thing you support forever). • And when APIs are broken intentionally, it may be unavoidable necessity. Sometimes some external dependency changes (OS, hardware, other APIs, 3rd party vendors, laws) and the breakage has to be propagated through. Sometimes APIs reach their scaling limits and can't support increased amounts of data (in library APIs you may have O(n^2) interface, in web APIs you may have exposed something that requires full DB sort or scan, in binaries you may run out of bits in field sizes).

by vemv 6y ago

betenoire 6y ago

nah the author addresses this: > Make a new thing, name it something else, figure out the migration that makes sense for you and your users. If you follow that advice, you don't have a broken API and the rest still follows.

vemv 6y ago
It's also possible to follow the alternative and still keep breaking APIs. It's much more effective to focus on a single thing (breaking change rejection) than to pretend that one thing can be magically accomplished through another.
- betenoire 6y ago
  yeah, the scheme doesn't somehow prevent you from breaking your API. that's still on us :)
pornel 6y ago
That doesn't fix anything. • Most often people break semver by accident, so they wouldn't know when a release should have been "a new thing" instead. You can't replace QA with a versioning scheme. • Hyrum's Law means you can't really change anything without risk of breaking someone somewhere. It's hard to know what can you change without breaking someone. If you try to never break anything, it leads to absurd trade-offs (every release becomes a thing you support forever). • And when APIs are broken intentionally, it may be unavoidable necessity. Sometimes some external dependency changes (OS, hardware, other APIs, 3rd party vendors, laws) and the breakage has to be propagated through. Sometimes APIs reach their scaling limits and can't support increased amounts of data (in library APIs you may have O(n^2) interface, in web APIs you may have exposed something that requires full DB sort or scan, in binaries you may run out of bits in field sizes).