4 ms·

What you're saying is totally true and the only pragmatic way to update/release. But it is a shame that if the api update compiles you can't expect things will

What you're saying is totally true and the only pragmatic way to update/release. But it is a shame that if the api update compiles you can't expect things will just work the same way.

danpalmer 3y ago
This is why you set a version number for the API you want. No type system in wide production use is able to encode the semantics of APIs sufficiently. Many of the best APIs out there have version numbers that allow you to pin the API structure and semantics – GitHub and Stripe come to mind with this.
- skinner927 3y ago
  There’s this company out of I think Washington state who builds an operating system for x86 and x64 systems. I know for a fact that GUI applications from 15 years ago still work on the modern version. It’s called Microsoft Windows. You should check it out. The win32 api has changed but it’s backwards compatible.
  - deleted 3y ago
    [deleted]
  - danpalmer 3y ago
    Windows has "Compatibility Mode" to support these things. Additionally there are layers and layers of Windows API – an app built against Windows XP may still work but it's not using the same tech as one built for the current version of Windows. This is part of the reason that users always had to install different versions of .NET, or part of the reason why Windows is a huge OS (API surface area, disk usage) in a way that isn't suitable for mobile devices. Yes MS are better at backwards compatibility, but everything is a tradeoff and they receive plenty of criticism for the direction they take. Desktop computing has different constraints and is moving much more slowly than mobile computing, so it's more feasible to maintain that compatibility.