2 ms·

Yeah this pushes developers of the platform between a rock and a hard place. It's ok to keep backwards compatibility, but the API needs to also move forward an

Yeah this pushes developers of the platform between a rock and a hard place. It's ok to keep backwards compatibility, but the API needs to also move forward and get the bugs ironed out. The worse case is when developers start to rely on the bugs for their workarounds (yes, please, do test your API before releasing) Maybe shims are the way to go. Instead of keeping old functionality around you make a shim that only talks to the new API. And that will serve as a guide (because if you're taking functionality out that's usually not good). I've seen a couple of cases where the deprecated API was much more straight forward and easy to use than the new one. Not good.

madia_leva 5y ago
We are talking about APIs (Application Programming Interfaces), not implementations. Of course you are free to change the implementation of your API at any moment, as long as you keep the semantic and performance characteristics. If you have a much improved design which allows for a better implementation then it would be perfectly fine if you reimplement the old API on top of the new API. As long as this is strictly transparent (source and binary, if this makes sense), then why not. Linus attitude about not breaking user space is the correct one.