Avoiding fragmentation with a rolling release

Loïc Minier loic.minier at ubuntu.com
Mon Mar 4 09:36:53 UTC 2013


On Sat, Mar 02, 2013, Martin Pitt wrote:
> Loïc Minier [2013-03-01 12:10 +0100]:
> > I don't think we can make any commitment against all of Ubuntu or all of
> > main, but we could pick a subset by product and commit to some level of
> > API and ABI support for this subset.
> 
> I still disagree. A few years ago we heavily promoted quickly+pygtk2
> as THE app dev platform, only to deprecate it about a year later when
> gobject-introspection and GTK3 came along. After that has caught on
> for a while, we are now telling people "forget about GTK, use Qt/QML
> as app dev API". The former was already on the horizon at that time,
> and we were fully responsible for the latter by ourselves.
> 
> Who knows what the app dev API du jour will be after 14.04? It's not
> totally inconceivable that we'll go back to e. g. GI and JavaScript,
> as upstream GNOME currently intends to do, or even to different APIs
> that are being used by other OSes (Android, FirefoxOS, and the like).
> 
> We shouldn't make promises which we cannot guarantee to hold, so let's
> rather be clear and say "this is the API for *this* LTS".

I don't think this is contradictory; it would be fine to deprecate
API/ABI in one LTS to remove it in the next for instance.  Still, we do
need to pick a subset and commit to supporting it at least until the
next LTS (inclusive).

Still, while I can't exclude that there will be reasons to consider yet
another API, we should try hard to pick a stable API and stick to it.

In fact, it might be multiple APIs; such as one Qt/QML high-level API,
a C/C++/OpenGL + some libs lower level API, an API for HTML5/webapps to
integrate in the launcher etc.

-- 
Loïc Minier



More information about the ubuntu-devel mailing list