Ubuntu Still Talking About A Stable App API/ABI
At the Ubuntu 12.04 Developer Summit that happened two years ago there was talk of coming up with a stable API for application developers outside of the kernel area.
The hope by Ubuntu back in 2011 was to produce more documentation and a stable API on the desktop side to assist application developers. The interfaces back then to make up this stable Ubuntu platform API were GNOME 3, GObject, libunity, libappindicator, GSettings, and Ubuntu One. Their call for this stable API was on the desktop (higher-level) side to help application developers target multiple Ubuntu releases and overall make it a better experience and comparable to that of writing an app for Windows or OS X.
Two years later, the Ubuntu developers are still wanting a stable API and ABI for apps. Of course, in the past two years a lot has changed. Now Canonical has a much greater focus on pushing their mobile ambitions. What they were looking at two years ago for their "stable" Ubuntu platform APIs is also much out the window. Unity 8 is a whole new shebang and they're far less dependent upon GNOME, Unity 8 is happening in Qt, and they also have their own Mir display server, among other changes and Canonical coming up with more of their own libraries/packages.
Today at the Ubuntu 14.04 virtual Developer Summit there was a session on "System framework for apps" where the stable API/ABI talk kept on going. The Ubuntu developers are still determining what to recommend app developers built against, what Canonical is to build their own Click packages against, how to support building against SDK versions, how to support running Click packages against older/newer packages, and what they can promise about API or ABI stability.
Years after the stable Ubuntu API/ABI discussions first started happening, they are still deciding about publishing a list of supported API/ABIs, testing and handling of API/ABI changes, etc. This is nothing about a stable kernel API/ABI or anything low-level and crazy like user-space drivers, etc.
One of the approaches talked about is utilizing a run-time chroot for changing supplied libraries to a package. This would likely be a nightmare with needing to maintain multiple chroots on the system for all supported runtimes. "Generating a chroot seems very heavy in terms of disk usage, might have to support 3-4 releases in parallel, of some hundreds of MB each..Ideally we would like to promise ABI and API stability for ever. However this has a cost. An upper bound might be the supported timeline of the Ubuntu releases. But it could be a lot less than that."
In the end, not too much was decided during the hour-long conversation, but the video is embedded below and the vUDS notes can be found on the session page.
20 Comments
