Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
If applications will be broken, then the API shouldn't change.
If there are no applications using an API, that API can be removed.
But If applications are using that API, creating new versions of the API doesn't solve the problem. Existing applications are not going to disappear.
This attitude that "the APIs are versioned, we can drop support for old versions" is exactly what's causing the problems in the Linux Desktop Environment world.
It doesn't matter how justified you think you are in getting rid of an old version, if it breaks users it's a regression and you should not do so.
Maintaining lots of different, incompatible versions of an API is a huge amount of work, so just versioning the API isn't nearly enough, and it's questionable if it really helps in the long run.
EPOLL_CTL_DISABLE, epoll, and API design
Posted Oct 23, 2012 23:04 UTC (Tue) by nybble41 (subscriber, #55106)
However, I agree that in general maintaining multiple API versions, where the old one is not a simple subset of the new one, is not likely to go well.
Posted Oct 25, 2012 9:42 UTC (Thu) by dgm (subscriber, #49227)
For that reason we should be putting much more effort into API design. In fact, tacking into account that API _will_ outlive its implementation (maybe several of them), most of the effort should be towards getting the API right.
Re API (and ABI) design and maintenance
Posted Oct 26, 2012 18:31 UTC (Fri) by davecb (subscriber, #1574)
I spent three years at the (late, lamented) Sun Microsystems doing ABI stability, and ended up sensitized enough that I notice it when it happens.
An easy example was a company's linker, which needed a different data structure for a method call that it had. We added a new "record type" in tghe linker, and converted the compilers to produce only it. We supported the old format for a year, then made its use produce a warning, and a year after that, made it require a link-line option.
We got two complaints, total, about the option. Out of all our customers, only two were so very very far behind that they ran one of the old compilers. A year or two later a hardware change made those compilers produce impossibly lousy code, and the two outliers upgraded to the new compilers. Then we retired the old interface.
If we had moved any faster, we would have annoyed at least two customers. If we had moved any slower in switching the compilers over, we would have made the OS developers unhappy. The time between the first switch and the final stages of the retirement made the maintainers unhappy, but there weren't many bugs in that interface nor were there many user of it, so the time cost of maintaining it was low.
We did have to manage it, and we had to do a fair bit of work behind the scenes to make it invisible to the users, but we succeeded at evolution.
Just as with humans, if you don't evolve, you might just die out. Homo habilis, anyone?
Posted Nov 13, 2012 12:39 UTC (Tue) by k3ninho (subscriber, #50375)
I suspect that Linus' view on never, ever, binning old binary interfaces will mean that there will be (un)dead interfaces supported forever. My thoughts on a management plan look like:
(*) build a test suite round existing, in-use interfaces to maintain their intended functionality
(*) build a versioning API where a version-aware program can call in to use versioned interfaces
(*) attach version info to the existing APIs and handle a 'this interface is not implemented in your version of Linux' error
(*) develop a plumbing metalanguage to support disabled/legacy interface functionality via newer intefaces
(*) have all the interfaces configurable in the makefile, defaulting to enabled
(*) stop talking and show you some code
Posted Nov 15, 2012 17:15 UTC (Thu) by nix (subscriber, #2304)
Posted Nov 19, 2012 6:44 UTC (Mon) by k3ninho (subscriber, #50375)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds