Re: Gtk+4.0
On Thu, Jul 7, 2016 at 11:30 AM Emilio Pozuelo Monfort wrote: > Hi, > > On 21/06/16 16:26, Peter Weber wrote: > > I don't see here an active discussion about Gtk+4.0[1]? So I'm trying to > > write about my thoughts, in a careful way. In the first moment, I thought > > this is a good idea and just the numbering is misleading. Stability is > what > > developers want, we need it, we love it. With a few days distance, > > numbering is just a small issue, I see this now entirely different and > > three major issues: > > Here are some thoughts I have about all this, from a downstream maintainer > POV. > Thanks! It's good to get opinions from all over the place. My concern with this new scheme is that GTK+ libraries will have to bump the > soname every 6 months (if they want to support the latest GTK+). That can > be > manageable for say vte or gnome-desktop, although it may be bad if some > third > party apps pick a dependency on the vte for GTK+ 4.2 but don't update it > for > GTK+ 4.4, as then distros would need to ship an increasing number of > versions > that are unlikely to get any support upstream. > I'm expecting this will become less and less of a problem as apps move to Flatpak as a means of distribution. But do you expect WebKitGTK+ to bump the ABI every 6 months? > That does seem to point to a problem — if an app uses Library X which does follow the unstable GTK series, and Library Y which doesn't, then the app developer is forced to stick to the stable series of GTK and an old version of Library X in order to accommodate Library Y. Any thoughts? I feel like the X.[024] releases are just snapshots of a development branch, > with X.6 being the stable release, and I wonder if X.[024] shouldn't > clearly be > labelled as that, regardless of what version number is chosen (be it 4.0, > 3.99.0, 4.0beta1 or whatever). > In my opinion the label "unstable release" communicates exactly that. I'm not sure what "development branch" communicates that "unstable release" doesn't? Regards, Philip C ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+4.0
On Sat, Jul 9, 2016 at 12:06 PM, wrote: > On Thu, Jul 7, 2016 at 11:30 AM Emilio Pozuelo Monfort > wrote: > >> Hi, >> >> On 21/06/16 16:26, Peter Weber wrote: >> > I don't see here an active discussion about Gtk+4.0[1]? So I'm trying to >> > write about my thoughts, in a careful way. In the first moment, I >> thought >> > this is a good idea and just the numbering is misleading. Stability is >> what >> > developers want, we need it, we love it. With a few days distance, >> > numbering is just a small issue, I see this now entirely different and >> > three major issues: >> >> Here are some thoughts I have about all this, from a downstream >> maintainer POV. >> > > Thanks! It's good to get opinions from all over the place. > > My concern with this new scheme is that GTK+ libraries will have to bump >> the >> soname every 6 months (if they want to support the latest GTK+). That can >> be >> manageable for say vte or gnome-desktop, although it may be bad if some >> third >> party apps pick a dependency on the vte for GTK+ 4.2 but don't update it >> for >> GTK+ 4.4, as then distros would need to ship an increasing number of >> versions >> that are unlikely to get any support upstream. >> > > I'm expecting this will become less and less of a problem as apps move to > Flatpak as a means of distribution. > How does Flatpak solve this problem? > But do you expect WebKitGTK+ to bump the ABI every 6 months? >> > > That does seem to point to a problem — if an app uses Library X which does > follow the unstable GTK series, and Library Y which doesn't, then the app > developer is forced to stick to the stable series of GTK and an old version > of Library X in order to accommodate Library Y. > > Any thoughts? > > I feel like the X.[024] releases are just snapshots of a development >> branch, >> with X.6 being the stable release, and I wonder if X.[024] shouldn't >> clearly be >> labelled as that, regardless of what version number is chosen (be it 4.0, >> 3.99.0, 4.0beta1 or whatever). >> > > In my opinion the label "unstable release" communicates exactly that. I'm > not sure what "development branch" communicates that "unstable release" > doesn't? > The convention in GNOME up until know has been that even numbers are for stable releases, and odd ones are for unstable releases. I didn't know GTK+ 4.0 would be considered an unstable release. > Regards, > Philip C > > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-devel-list > > -- Jasper ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+4.0
On Sat, Jul 9, 2016 at 12:06 PM wrote: > On Thu, Jul 7, 2016 at 11:30 AM Emilio Pozuelo Monfort > wrote: > >> Hi, >> >> On 21/06/16 16:26, Peter Weber wrote: >> > I don't see here an active discussion about Gtk+4.0[1]? So I'm trying to >> > write about my thoughts, in a careful way. In the first moment, I >> thought >> > this is a good idea and just the numbering is misleading. Stability is >> what >> > developers want, we need it, we love it. With a few days distance, >> > numbering is just a small issue, I see this now entirely different and >> > three major issues: >> >> Here are some thoughts I have about all this, from a downstream >> maintainer POV. >> > > Thanks! It's good to get opinions from all over the place. > And, speaking of that, there was a blog post [1] on the GTK 4 subject that recently got a lot of attention on Hacker News. I reached out to the author and encouraged them to give their opinion here, but it seems the message is stalled in the moderator queue. Is there a moderator who can help? [1] https://davmac.wordpress.com/2016/07/05/why-do-we-keep-building-rotten-foundations/ Regards, Philip C ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+4.0
On Sat, Jul 9, 2016 at 12:13 PM Jasper St. Pierre wrote: > On Sat, Jul 9, 2016 at 12:06 PM, wrote: > >> On Thu, Jul 7, 2016 at 11:30 AM Emilio Pozuelo Monfort >> wrote: >> >>> Hi, >>> >>> On 21/06/16 16:26, Peter Weber wrote: >>> > I don't see here an active discussion about Gtk+4.0[1]? So I'm trying >>> to >>> > write about my thoughts, in a careful way. In the first moment, I >>> thought >>> > this is a good idea and just the numbering is misleading. Stability is >>> what >>> > developers want, we need it, we love it. With a few days distance, >>> > numbering is just a small issue, I see this now entirely different and >>> > three major issues: >>> >>> Here are some thoughts I have about all this, from a downstream >>> maintainer POV. >>> >> >> Thanks! It's good to get opinions from all over the place. >> >> My concern with this new scheme is that GTK+ libraries will have to bump >>> the >>> soname every 6 months (if they want to support the latest GTK+). That >>> can be >>> manageable for say vte or gnome-desktop, although it may be bad if some >>> third >>> party apps pick a dependency on the vte for GTK+ 4.2 but don't update it >>> for >>> GTK+ 4.4, as then distros would need to ship an increasing number of >>> versions >>> that are unlikely to get any support upstream. >>> >> >> I'm expecting this will become less and less of a problem as apps move to >> Flatpak as a means of distribution. >> > > How does Flatpak solve this problem? > If an app was released as a Flatpak, it would target a Flatpak runtime. There would not be a choice between targeting VTE-for-GTK-4.2 or VTE-for-GTK-4.4, and so distributions would not need to ship a VTE-for-GTK-4.2 straggler that some app was still targeting. But do you expect WebKitGTK+ to bump the ABI every 6 months? >>> >> >> That does seem to point to a problem — if an app uses Library X which >> does follow the unstable GTK series, and Library Y which doesn't, then the >> app developer is forced to stick to the stable series of GTK and an old >> version of Library X in order to accommodate Library Y. >> >> Any thoughts? >> >> I feel like the X.[024] releases are just snapshots of a development >>> branch, >>> with X.6 being the stable release, and I wonder if X.[024] shouldn't >>> clearly be >>> labelled as that, regardless of what version number is chosen (be it 4.0, >>> 3.99.0, 4.0beta1 or whatever). >>> >> >> In my opinion the label "unstable release" communicates exactly that. I'm >> not sure what "development branch" communicates that "unstable release" >> doesn't? >> > > The convention in GNOME up until know has been that even numbers are for > stable releases, and odd ones are for unstable releases. I didn't know GTK+ > 4.0 would be considered an unstable release. > There are several different version numbering schemes proposed on this wiki page [1]. I was referring to the term "unstable release" versus "development branch". [1] https://wiki.gnome.org/Projects/GTK%2B/Lifecycle ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+4.0
On Sat, Jul 9, 2016 at 12:36 PM, wrote: > On Sat, Jul 9, 2016 at 12:13 PM Jasper St. Pierre > wrote: > >> On Sat, Jul 9, 2016 at 12:06 PM, wrote: >> >>> On Thu, Jul 7, 2016 at 11:30 AM Emilio Pozuelo Monfort < >>> poch...@gmail.com> wrote: >>> Hi, On 21/06/16 16:26, Peter Weber wrote: > I don't see here an active discussion about Gtk+4.0[1]? So I'm trying to > write about my thoughts, in a careful way. In the first moment, I thought > this is a good idea and just the numbering is misleading. Stability is what > developers want, we need it, we love it. With a few days distance, > numbering is just a small issue, I see this now entirely different and > three major issues: Here are some thoughts I have about all this, from a downstream maintainer POV. >>> >>> Thanks! It's good to get opinions from all over the place. >>> >>> My concern with this new scheme is that GTK+ libraries will have to bump the soname every 6 months (if they want to support the latest GTK+). That can be manageable for say vte or gnome-desktop, although it may be bad if some third party apps pick a dependency on the vte for GTK+ 4.2 but don't update it for GTK+ 4.4, as then distros would need to ship an increasing number of versions that are unlikely to get any support upstream. >>> >>> I'm expecting this will become less and less of a problem as apps move >>> to Flatpak as a means of distribution. >>> >> >> How does Flatpak solve this problem? >> > > If an app was released as a Flatpak, it would target a Flatpak runtime. > There would not be a choice between targeting VTE-for-GTK-4.2 or > VTE-for-GTK-4.4, and so distributions would not need to ship a > VTE-for-GTK-4.2 straggler that some app was still targeting. > Er, so, with this model, we're working around the fact that we're breaking ABI without changing the soname? If we're relying on Flatpak to solve this, why bother bumping the soname at all and releasing new stable versions? It's effectively no different from having GTK+ 4.8, since it still breaks every release. In fact, this could be a new plan. If we double down on Flatpak, then we could simply not bump soname / major version, leave it at 4, break ABI every point release, and have the ".6-multiple" releases be LTS releases which are "maintained more than most". This doesn't solve the fact that application development is more difficult inside a Flatpak, and not all application authors are going to have to want to maintain Flatpaks and an infrastructure to build and test them. > But do you expect WebKitGTK+ to bump the ABI every 6 months? >>> >>> That does seem to point to a problem — if an app uses Library X which >>> does follow the unstable GTK series, and Library Y which doesn't, then the >>> app developer is forced to stick to the stable series of GTK and an old >>> version of Library X in order to accommodate Library Y. >>> >>> Any thoughts? >>> >>> I feel like the X.[024] releases are just snapshots of a development branch, with X.6 being the stable release, and I wonder if X.[024] shouldn't clearly be labelled as that, regardless of what version number is chosen (be it 4.0, 3.99.0, 4.0beta1 or whatever). >>> >>> In my opinion the label "unstable release" communicates exactly that. >>> I'm not sure what "development branch" communicates that "unstable release" >>> doesn't? >>> >> >> The convention in GNOME up until know has been that even numbers are for >> stable releases, and odd ones are for unstable releases. I didn't know GTK+ >> 4.0 would be considered an unstable release. >> > > There are several different version numbering schemes proposed on this > wiki page [1]. I was referring to the term "unstable release" versus > "development branch". > The messaging here is very confused and inconsistent, and I think that's one of our major stumbling blocks here. I would be happier with "4.0alpha", "4.0beta", "4.0rc", "4.0final" or similar, rather than the .[024] which imply stability with our current version naming scheme. > [1] https://wiki.gnome.org/Projects/GTK%2B/Lifecycle > -- Jasper ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+4.0
Hi! On Sat, 2016-07-09 at 19:06 +, philip.chime...@gmail.com wrote: > I'm expecting this will become less and less of a problem as apps move > to Flatpak as a means of distribution. Uhuuu. I'm sorry, but this is bad. This mixes two completely different problems together, packaging and a toolkit. So enforcing Flatpak on distributions, developers and users should solve a problem with Gtk+? While Flatpak offers some nice features (especially easy install of out-of-repo software), it includes so many problems that it cannot replace package-management. The constant work done by the downstream-maintainers makes GNU/Linux so well usable, it is not burden but a duty. Flatpak problems: * increased memory consumption * security fixes are not available for all applications * basically all things dynamic-libraries have fixed... * security and door-keeper function of distributions lost * much more work for developers If Gtk+ is allowed to be installed within a Flatpak the increased memory consumption will be vast. I pretty sure that Jasper is right about the "targets", including Gtk+ is not(?) allowed because it will blow up your system. More about the issues with Flatpak (Archlinux): http://kmkeen.com/maintainers-matter/2016-06-16-11-31-07-560.html Solving a problem with another problematic approach isn't a good idea. Peter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
