https://media.ccc.de/v/7-inspector_gadget#download
I want suggest viewing the record of Benjamin Otte's talk about "Gtk Para...Inspector" at GUADEC 2016! Which is, indeed, only about Gtk-4.0 and the follwing development model! I think Benjamin has done a great job in calming everyone down and explaining the thinking behind the planning. You should take the time to view it completely, but timecode 07:00 (two year-cycle and feature vs. time-based) and timecode 10:00 (depending libraries like GktSourceView) are interesting. Furthermore he explained to me (afterwards) very nicely why the bump to Gtk4 itself is required, the old internals of X11 are still built inside Gtk3 and working behind it's Wayland-backend from old times. So cleaning the things up is necessary. I can't say if bumping to Gtk4 would also be a good idea looking at GSK, manuelle Bassi knows this better. The other thing is the development-model following after first release of Gtk4. I can feel the churn and tension between your lines "suicide" and Emanuelles "who does the work in gtk development". Gtk is the GNOME-Toolkit and it's fine, if XFCE or Cinnamon put work inside Gtk it could also named the GNU-Toolkit. That naming thing is not the point. Library-developers want a clean and lean library (API/ABI breaks), while application-developers need stability (avoid API/ABI breaks) and both together want new and nice features (the thing which makes it difficult)? As longer a library keeps stable and moves also ahead with some new features, as more tolerable and enjoyable breaks of the API/ABI become from time to time. Everyone is willing to pay a price for a good thing. Just extending the stability period on four years will not fix it. It's hard for me to explain, so bear with me. What causes a chilling effect is the split-up into unstable and stable and that every release of the stable-series will be a major-release, which really breaks everything. The reasonable expectation is a system with major, minor, patches: Major: add new features, cleans up API/ABI, break API/ABI Minor (missing here): add new features, shouldn't break, but maybe if absolutely required and easy to keep up with it Patch: and patches, doesn't break anything, doesn't add anything This is the model of Qt and it works. Noteable, Qt has done more majors (5 vs 3) than Gtk and Qt5 has done less minors than GTK3 (10 vs 7). Maybe also the unstable-release could be used internally as long as the developers wish (why not rolling permanentely?), good things can be ported back to a new minor release of Gtk4. And if the issue arises that unstable collected cool new stuff which requires a major-release after a unkown number of years, than this new major-release will be created and labled Gtk5. If this happens after ~three years, okay. If this happens after ~six years, nice. Anything longer would be a pure miracle and maybe not good (Gtk2 is more like a dinosaur). I think breaking the API/ABI because of required changes, is right, breaking API/ABI because a fixed number of months has passed doesn't make much sense. I think Benjamin is right here, application developers are willing to pay for an API/ABI break if they receive incredible, required new stuff they can't get in another way. Peter PS: Thanks for your talks on GUADEC. Sadly I missed the last day :( _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list