On 09/07/16 20:42, Jasper St. Pierre wrote:
> 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".
Speaking as a distribution (Debian) developer: breaking the ABI without
bumping the SONAME is really frustrating to deal with in distributions;
so if there will be anything that uses Gtk and is ever distributed in
ways other than Flatpak and similar things, please manage the Gtk SONAME
correctly.
gnome-shell, gnome-control-center and gnome-settings-daemon, together
with their forks in GNOME derivatives like Cinnamon, are among prominent
packages that depend on Gtk but should be part of the distribution's
release process, even in a possible future where ordinary apps are
exclusively distributed via Flatpak. (I don't think that future has
arrived yet, in any case.)
Now for the comedy part of the discussion. I'd like to follow through on the double-down-on-Flatpak proposal, even if Jasper didn't mean it seriously. I don't mean it entirely seriously either, since it has some serious flaws detailed below, but it does address some of the concerns I summarized in my email from just now [1].
The stable series would be much as in the original GTK 4 proposal, but it would just be called "GTK". That indicates to outsiders who don't care about release schedules and just want a GUI toolkit, that this is the toolkit to use. GTK would receive bugfixes, and possibly backports of new features if maintainer time and inclination allows.
The unstable series would get a different name that isn't "GTK", e.g. "GTK-Next", and become (imagine air quotes around this) "Flatpak-only".
Air quotes because it would of course still be released as a source tarball, and if a distro wanted to package it of course no-one could stop them; but we would discourage it from being available through distro package managers. Air quotes also because it wouldn't be limited to Flatpak on Linux; I would for example be able to build GTK-Next and bundle it inside an application bundle on Mac OSX. That use would also be encouraged, as well as its equivalent on Snappy, as well as whatever application sandboxing solution arises on any other platform in the future.
But as far as GNOME is concerned, GTK-Next would be released first and foremost as part of the org.gnome.Platform Flatpak runtime.
This does cut off system components such as gnome-control-center from using GTK-Next, as Simon pointed out above.
This would also leave applications in somewhat of an awkward position if they wanted to use GTK-Next but needed to use a library that depends on GTK, such as GtkSourceView, VTE, or WebKitGTK. I see two possibilities here:
1) if the library maintainer is amenable to doing the work, the library could have a GTK-Next branch with a separate pkg-config name, and this would be released with the same intention and through the same channels as GTK-Next.
2) if the library maintainer is not interested, the application author would have to port the library to GTK-Next themselves and bundle it in their application.
The worst part of this proposal is that it makes it very hard for app maintainers to use GTK-Next if they want to keep releasing their app in the traditional manner, not as a Flatpak or other bundle. They could decide to maintain a separate GTK version alongside the GTK-Next version of their app, but that's a really crappy story to sell to developers. Maybe we could include some tooling which would make it easy for GTK-Next to be built as an application's internal library in pkglibdir? It might mean that in practice the only users of GTK-Next would be applications like GNOME Documents and GNOME Music, which would be a shame. It would also feed the perception that GTK is primarily there for the consumption of GNOME and other consumers are an afterthought.
The pros of this proposal are that it's crystal clear that GTK-Next is opt-in only, and the bulk of the extra work falls onto the people who opt-in. It removes packagers and distros from the equation entirely and so will not cause them more work. Put bluntly, the idea is to make it harder for app maintainers to opt-in to the unstable series if they aren't serious about keeping up with the porting work, as well as limiting the damage they can do if they leave an app stuck on an old version of GTK-Next.
No version numbering schemes were harmed in the making of this email.
Happy hacking everyone,
Philip C
