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? _______________________________________________ gtk-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtk-devel-list
