gtk3 planning

[Colin Walters <walters verbum org>]

Hi,

So I'm really concerned about what I see as the current GTK+ 3.0 plan,
which is to release a frozen 3.0 in August.  At that point, we'll have
*two* ABI frozen libraries that are 92.3% the same.  That's a really
unfortunate situation, especially since a good chunk of the features
that are currently in 3 could just as well (with some extra elbow
grease perhaps) have landed in 2.

There are also some things (like the theming changes) that appear at
high risk of not landing in 3.  As far as I understand it, someone did
some benchmarks hacking out the native theming stuff from Firefox, and
got dramatic speedups.  If this doesn't land in GTK3, we're losing a
lot of the potential value we got from the ABI break.

Let me make a concrete proposal, which is basically:

* GTK3 as fast-moving, 1-1.5 year cycle series of libraries, GTK2
continues to be maintained and gain features

So in August, GTK 3.0 is released.  For applications that want to hop
on the feature train, they can port to GTK 3.0 and we maintain a lot
of API compatibility with 2.  One year from then, we release GTK 3.2
which breaks API/ABI again.   Then some point later, GTK 3.4 is
released.  And so on; this could continue for a few years (say until
we reach GTK 3.10), then we can perhaps call it stable, and at that
point can attempt a mass-conversion of the remaining GTK 2 programs.

For people using GTK+ on Windows/OSX, the frozen API is less important
because you have to ship GTK+ with your app, so you choose/maintain
your version.  For Linux-based operating system constructors, we need
to ship GTK2 for the forseeable future.  We would however ideally ship
GNOME 3 with the core apps linked to GTK 3.0.  Then because we have
the source code to all of these, we can port them again.  We would
expect Linux operating system constructors to *not* simultaneously
ship GTK 3.x and GTK 3.y.  So we would be explicitly asking
proprietary software vendors not to link to it - (or if they do, ship
it with their app; we could perhaps make this easier by maintaining a
stable 3.0 API for themes and input modules).

The lifecycle here is flexible - we could say 1 year, 2 years, 6
months, or it could vary.  The point ultimately is again that having a
permanently frozen GTK 3 with no possibility to do further changes is
the worst of both worlds, since now we have two 92.3% similar
straightjackets.

Thoughts?