On Tue, 21 Jun 2016 17:07:46 +0100, Simon McVittie
<simon mcvittie collabora co uk> wrote:
> Ideally, we'd choose the trade-off such that projects that want to stick
> to a stable-branch version are happy with its stability, while also not
> feeling that they are missing out on too much new stuff by doing so. A
> year is probably too fast? 5 years is probably too slow? I don't know
> what the right middle ground between those two is, but 2 years sounds
> like a good first guess.
I started to think about it this. I tend to compare Gtk with Qt, but they
are not the same. On the other hand, Gtk and Qt are only major
platform-independent toolkits and largely used on GNU/Linux. The active
phase of Gtk2 lasted from 2001 - 2011 and it is still maintained in 2016,
which is a scary long time. Qt's cycle is much shorter, they moved from
2.x till 5.x in same time frame.
The current proposal will split Gtk into stable branch, which will break
in an insupportable* short-period of two years. Even if some major
applications will move immediately to a stable release, they will already
use the out-dated within two years. Furthermore GNOME will not use "Gtk",
GNOME will use it's own Gtk which will likely look and feel different in
several ways(HIG?). I'm afraid support for at least the development Gtk,
the stable Gtk and the old-stable Gtk will be required also.
* Thank you English language for this word!
10 Years are too long and 2 years are too short. Right? Is it better to
break the API/ABI clearly once and keep it stable for some years, maybe a
range between 4 to 6 years? In this area compatible (non-breaking)
features
can be added. I'm feeling far more comfortable with this idea. This sounds
similiar to Qt and maybe it's a good approach:
+ all applications will largely use the same toolkit (good for users)
+ reliable planning (application developers)
+ necessary API/ABI break (library developers)
+ less maintenance burden (library developers)
- not so many freedom through API/ABI break (library developers)
I would prefer a faster and more firm cycle.
I've tried to capture some of the discussion that we've had so far, on-list and off, in this FAQ [1]. I also added some points for further discussion, such as the longer cycle length you mentioned above.
Regards,
Philip C
