Hello! Writing this on webmail-client. Please bear with me.
On Tue, 21 Jun 2016 12:12:46 -0700, Christian Hergert <christ...@hergert.me> wrote: > Sorry for the long post, I tried to condense it, unsuccessfully. > ... Thanks! That is a valuable insight into the development and changes of Gtk3. An inspiration for the Gtk-Blog? On Tue, 21 Jun 2016 17:07:46 +0100, Simon McVittie <simon.mcvit...@collabora.co.uk> wrote: > Thanks for starting this discussion. > > A new stable-branch every 2 years is certainly not set in stone, just > like there's no reason there *has* to be a new stable release of Debian > approximately every 2 years. It's a trade-off between two factors. If > stable releases are too frequent, you're right that third-party > developers will either spend a disproportionate amount of time catching > up with the latest version, or go looking for something else. If stable > releases are not frequent enough, third-party developers will find that > they can't have the latest features or fixes (including the things that > can't be fixed without breaking API!) other than by using the unstable > branch. > > ... > > 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'm not one of the people doing the work, so I can't make an informed > comment on what future plans would require an API/ABI break. However, if > the people writing the code say they would benefit from API/ABI breaks, > it seems sensible to believe them. True and valid! Christian also has written much about this. How is the contact between the Gtk-Team with the application-developers of GIMP, Inscape, Pidgin, MySQL-Workbench, Geeqie, Firefox, LibreOffice, Wireshark, Gummi...[growing list of my day-to-day stuff]? I would ask them for their oppinions. In the end, they will use it. Bye Peter PS: Posting about the plans was a good decision, even if the churn is annoying. _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
