On Fri, Jun 25, 2010 at 12:50 PM, Matthias Clasen <matthias.cla...@gmail.com> wrote: > > Sure, we could continue to shoehorn features in to 2.x and it will > increasingly get harder, and the bugs will increasingly get harder to > fix.
What we need to *realistically* look at is what big features that aren't going to make 3.0 now will be able to land later without ABI breaks. > As long as I maintain the 2.x branch, it will be in maintenance mode > and closed to features. I will gladly give up maintainership of the > 2.x branch to you if you promise to port all the features that land > there to 3.x as well. Hmm? Features would obviously land on 3 first, then get backported to 2. > Fwiw, a big motivation for all the sealing business was to make it > possible that GTK3 _can_ move faster and incorporate more new stuff > without the need for disruptive ABI breaks. Can say davidz's RI stuff land post-3.0? Can "Full support for MPX and multitouch devices." Can "Revamp/rewrite the entire theming system."? I think the answer to all of those is "no". While I know some MPX code landed, as far as I'm aware none of the widgets have been updated to possibly take advantage of it. Do we really believe that we can do that (easily) in an API compatible way? > And the GTK3 plans always > included the idea to do more regular ABI breaks, say every 2-3 years > as well. So, I think we agree! 2 years sounds fine to me. However - and this is important - we really should avoid putting Linux operating system constructors in the position of possibly shipping multiple GTK 3.x versions. This means we need to communicate to application authors that they should be willing to *stay* on the train if they hop on. _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list