hi all; gtk has a policy of only releasing from current-stable and master; lack of resources, uncertainty on the actual usage, and unpredictability of some release policies have mostly prevented the creation of "long term support" branches.
distributors have historically been in charge of taking existing releases and adding patches to backport fixes from the current-stable branch (or even from master); the distributor-list mailing list has been created to allow some sort of awareness for patches, to avoid per-distribution silos. this has been raised a bunch of times on IRC and mailing lists, and the end result of the discussions has always been: "somebody should show up and do the work". recently, I wrote a strawman[0] for Clutter 2.0 to detail a possible policy for LTS releases from the get go, instead of ex post facto. I think it would be good to have the same policy for GTK+ and maybe GLib. this means: • identifying the current branch of GTK+ 3.x being used by "stable" distributions (Ubuntu LTS, OpenSuse, RHEL, Debian stable); • finding a maintainer in charge of getting the patches from distributors and maintainers, integrating them, and spinning releases. the commonly used release of GTK+ 3.x seems to be 3.4, at least for Debian and Ubuntu. as for a volunteer for the latter point, I nominate myself - I've been releasing Clutter for the past 6 years, and given the patches flow, I can devote a reasonable slice of time to do this at least until the next LTS cycle. thoughts? ciao, Emmanuele. [0] https://live.gnome.org/Clutter/Strawman/LongTermSupport -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi/ _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list