4 ms·

> There's no way to entirely avoid breaking compatibility. Why?

• masklinn 5y ago
  Because you've got no idea how your code's being used in the wild an one person's bug is an other's feature. So any observable change in behaviour is a possibly breaking change. And then people go and muck with your internals even if you protected them, because that's the only way they found to do what they needed to do, and they were much more interested in doing the thing than following your guidelines. And that's before even mentioning broken features which requires changes which will invariably break other stuff. The only way to know for sure you're never breaking compatibility is to never release any update. Otherwise you're playing the odds.
  • dmoy 5y ago
    https://www.hyrumslaw.com/ https://www.hyrumslaw.com/ Also more facetiously, xkcd/1172
    • jnxx 5y ago
      That might be a real issue for people which strive for a high level of compatibility, such as engineers at Google, but I don't think it applies to less than 0.1% of compatibility-breaking changes. Also, such things are fixable if they are important - just provide the old behavior by default and add a flag or keyword argument which selects the updated behavior. And it also helps to make clear that the documented behavior is what you promise, nothing else. I think API breakages are usually just caused by developers which failed to define consistent and thought-out interfaces from the start, and library developers which do not want to do any extra work to continue to provide APIs with the old semantics. I know that it can be made to work, because I have worked in industrial automation and PLC libraries, and while there are not always and everywhere geniuses at work, in this field legacy interfaces are just never scrapped because they need to continue to work. What you publish needs to continue to work for 20+ years, because nobody wants to scrap a six-figure printing machine just because of an update to the PLC libraries. So, it does not require geniuses to do that. It is more a matter of what the consumers of a library tolerate. And the same is valid for language evolution. Common Lisp for example, or C are extremely stable. Python users have come to tolerate a far higher amount of breakage and instability, but I do not buy that this is in any way technically required. The breakage might not matter that much if the code is only used in fast-moving start-ups of which 99% will be bust anyway in four years time. But there are domains where the costs of this are just too high, such as science projects, industrial automation, enterprise systems, and many more, because systems are too complex and expensive to update.
    • jnxx 5y ago
      Also, Hyrums law are about unforeseen breakage because people did not relay only on the documented API specification. This is undesirable, and in fact hard to avoid completely. But most breaking changes such as in semantic versioning major number changes do intentionally break client code, which is an entirely different thing. There are a few rules one can follow which make it pretty improbable that such foreseeable breakage will happen. And this will constitute more than 99.9% of API breakage - even more if you stipulate that undocumented features must not be relied upon, and client developers follow that rule. Developers relying on undocumented behavior is usually due to a lack of clear documentation, so it is largely avoidable, too.
  • simonw 5y ago
    Something that here a lot here is having comprehensive, trustworthy documentation. This gives you the moral high ground to adopt semantic versioning: the correct behavior is the documented behavior. If someone has code that relies on an undocumented method or undocumented behavior, it's fair game to break that with only a minor version bump. If your documentation isn't any good, SemVer is almost a fiction.
    • jnxx 5y ago
      I second that. Also, semantic versioning requires documentation to give specific meaning to an interface.