Re: Gtk+4.0

["Jasper St. Pierre" <jstpierre mecheye net>]

On Sat, Jul 9, 2016 at 12:36 PM, <philip chimento gmail com> wrote:

On Sat, Jul 9, 2016 at 12:13 PM Jasper St. Pierre <jstpierre mecheye net> wrote:

On Sat, Jul 9, 2016 at 12:06 PM, <philip chimento gmail com> wrote:

On Thu, Jul 7, 2016 at 11:30 AM Emilio Pozuelo Monfort <pochu27 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