GTK+, version numbering, and long-term support [LWN.net]

By Nathan Willis
September 28, 2016

GTK+ version 3.22 was released on September 21, bringing with it a range of improvements to Wayland support, gesture support for pressure-sensitive tablets, several new widgets, and more. The release also marks a turning point for how stable and development branches of the code will be maintained. Moving forward, the project is adopting a new scheme that allows it to designate certain stable releases for long-term support. The plan also breaks with past releases where version numbering is concerned, though the project is keen to downplay that change in favor of focusing on the support that stable releases will offer to downstream projects.

The new release scheme was announced on September 1 in a Google+ post and an accompanying blog post written by Allan Day. The blog post explains more of the background issues that led up to the decision to adopt a new scheme.

GTK+ has long used the traditional "major.minor.micro" numbering scheme (sometimes called semantic versioning) that was once the approach favored by free-software projects. Bumping the major number indicated a significant API break, breaking backward compatibility. Bumping the minor number to the next even value indicated a stable update, while the odd values designated development branches. Micro (or patch) releases were reserved for bug-fix updates.

$ sudo subscribe today
Subscribe today and elevate your LWN privileges. You’ll have access to all of LWN’s high-quality articles as soon as they’re published, and help support LWN in the process. Act now and you can start with a free trial subscription.

But, in the GTK+ 3.x era, Day notes, the project picked up significant development speed and also adopted a strict six-month release cycle. That pace has led to concerns over GTK+'s stability, particularly for projects other than GNOME, which shares many developers and other contributors with the GTK+ project. The GTK+ developers, however, want the project to be useful for a wide range of projects outside of GNOME, which prompted discussions earlier in 2016 about changing the release schedule.

Rethinking

In June, after the annual GTK+ hackfest, Allison Lortie announced the proposed change in a blog post that sparked a fair share of confusion and concern. Commenters were evidently perplexed by the proposal, which included difficult-to-parse statements like this:

"Gtk 4.0" is not "Gtk 4". "Gtk 4.0" is the first raw version of what will eventually grow into "Gtk 4", sometime around Gtk 4.6 (18 months later).

One early comment by "Alex" summed up much of the general reaction:

Why in all that is holy are you going to release unstable apis with x.0 versions? Why don’t you call them betas like all proper developers do and call the stable versions x.0?

To be fair, though, releasing x.0 versions that were unstable was certainly not the intent of the scheme announced. Rather, the plan was meant to suggest that GTK+ version 4 would continue to evolve over the course of the subsequent 4.y releases. Nevertheless, the confusion was demonstrably a problem. At GUADEC in August, the GTK+ team reexamined the topic with a promise to present an updated plan as soon as possible.

Rethinking again

The September 1 announcements, then, constitute that update, which will hopefully prove clearer to outsiders. In essence, the GTK+ x.0.0 releases moving forward will be designated stable, long-term support versions, with the project planning to release an x.0.0 release about once every two to three years. In between these releases, minor updates will also appear that may introduce new functionality. The minor releases will not be bound to a fixed six-month release cycle, however.

Next, the GTK+ development branches will be numbered x.9, to indicate that they are unstable releases being built in preparation for release x+1. This means that, in the future, there may be (for example) a stable, long-term support GTK+ 5.0 available, a series of updated releases (GTK+ 5.2, 5.4, and so on), and a development branch numbered 5.9.

Furthermore, any features deprecated in one x.0 release will be removed in the following x+1.0 release. This is another area where GTK+ has not historically had a strict policy, so stating and adhering to a regular deprecation formula will no doubt please many outside developers. The new plan also states that minor releases may add new widgets and update the GDK drawing backends used by the various window systems supported, but that no other changes will be made. Finally, micro releases for bug fixes and security updates will be made for three years.

Thus, the total lifespan of the x.0 long-term support releases will be three years. The wording is a bit ambiguous as to whether x.2 and other minor updates will also be supported for three years (potentially several months after the x.0 release), but that does not sound like the intent of the plan.

On a technical note, the blog post notes that future development releases of GTK+ will be labeled with the future stable release's version number in the pkg-config file, in order to make them parallel-installable with the current release. So, for example, the pkg-config file in GTK+ 3.90 will be gtk+-4.0, so it will not conflict with the current stable release, GTK+ 3.22.

Development releases are expected to appear about once every six months, all bearing version numbers in the x.9 range (e.g., x.90, x.92, x.94, etc.). That puts some indirect pressure on the project to release a stable y.0 release once the development version's minor number reaches .98, as Sébastien Wilmet noted on the GTK+ development list.

The new plan sets out a fairly regular numbering and release scheme but, of course, transitioning between the old and new schemes will be a tad awkward. This awkwardness takes the form of the new stable release, GTK+ 3.22, being declared the first long-term support version, even though it is not branded with an x.0 version number. Hopefully, that will be seen as a small price to pay for more predictable releases.

Downstreaming

The hope is that the plan for major and minor releases will better serve downstream project developers and Linux distributions. A guarantee of three years of security fixes should be enough for most Linux distributions, while the promise to make no significant changes to GTK+ internals in minor releases ought to be welcome news for downstream application developers. For distributions that offer their own long-term support releases with a lifespan longer than three years, Day asks that distribution representatives get in touch with the GTK+ project to develop a support plan.

Day's blog post also assures downstream developers that the project is committed to doing a better job of communicating changes—and of doing so in advance:

While the GTK+ team reserves the right to change API during development series, this does not mean that the whole GTK+ API will constantly break each release; only specific, and hopefully rarely used parts of the API may change, and if the changes are too extensive they will very likely be delayed to the next major development cycle. We’ll ensure that these changes are well-communicated in advance.

One of the other criticisms the project has faced in the past was that too many decisions were made within the relatively small set of core GTK+ developers, with that information not always making its way out into the wider GTK+ community in a timely fashion. The project must still deliver on this promise to ensure that changes are well-communicated to the outside world, but acknowledging the concern and making a public commitment to doing better are important steps.

Despite the increased emphasis on meeting the needs of downstream developers, there has not yet been a public statement from GTK+'s largest downstream project, GNOME, on whether (or how) it will adopt the same updated version-numbering and stability plan. In the past, GNOME and GTK+ version numbers have stayed in sync; with the newly announced plan, GNOME would have to adjust its numbering and release schedule as well in order to maintain that relationship.

Then again, perhaps no such change is warranted. A big part of the rationale for GTK+'s change was to better serve non-GNOME projects; enabling those two projects to move at different paces could be just what the developers want.

to post comments

GTK+, version numbering, and long-term support

Posted Sep 29, 2016 11:58 UTC (Thu) by ovitters (guest, #27950) [Link]

The initial proposed versioning scheme was not good. During GUADEC I repeated the various problems it would cause. As a solution I proposed doing a gtk-next (taken from the kernel). The scheme the GTK+ team came up with is pretty nice and works much better. We already use x.uneven y.90+ to indicate beta/rc quality so using something similar for the minor should be pretty recognizable.

> In the past, GNOME and GTK+ version numbers have stayed in sync;

That depends on how long you've been with the project. It took a while to get this in sync. It is very convenient to have all of the version numbers aligned but e.g. GNOME 2.28 (Sep 2009) came with GTK+ 2.18. It took quite a while to get the releases schedules aligned (to avoid problems like an stable GNOME wanting an unstable gtk+), then only after that worked for a while the version numbering was aligned. GTK+ wasn't always on a 6 months schedule!

GTK+, version numbering, and long-term support

Posted Sep 29, 2016 14:43 UTC (Thu) by pdewacht (subscriber, #47633) [Link] (24 responses)

So if I understand this correctly, every two-to-three year there will be a new major release, breaking API compatibility with previous releases? We'll end up with LTS distro releases shipping major version N, while bleeding-edge distros have purged everything but version N+2. That would put application developers in a horrible situation.

GTK+, version numbering, and long-term support

Posted Sep 29, 2016 15:30 UTC (Thu) by smoogen (subscriber, #97) [Link]

My understanding is that this is how things have been done in the past but without any naming convention to tell developers what may or may not be happening inside of GTK. So development was already in a horrible situation, they just played compiler lottery to see if they were selected to be sacrificed or not this "minor" release cycle.

[The fact that most developers weren't aware of this says that GTK has been pretty good about not throwing out everything every release]

GTK+, version numbering, and long-term support

Posted Sep 29, 2016 16:25 UTC (Thu) by otaylor (subscriber, #4190) [Link] (1 responses)

With the current setup (feature development done on a long-lived stable branch), if you are developing on a bleeding edge system, you already have the problem that the version on that system is not the same as what is on older distros - you are developing against GTK+ 3.22, say, but a target system might be running GTK+ 3.14. But it's very hard to know what features and behavior changes you are depending on until some user running with GTK+ 3.14 reports a bug. In the new model, you either target GTK+ 4 and support older distros, or target GTK+ 5 and do not support older distros. (Though it's also much safer to add GTK+ 5 to an older distro than it is to upgrade the system GTK+ from 3.14 to 3.22.)

[ The third option is that you target GTK+ 5.9x and require your app to be updated in lock-step with GTK+ releases, but this is not a recommended route for most application developers. ]

GTK+, version numbering, and long-term support

Posted Sep 30, 2016 10:12 UTC (Fri) by chrisV (guest, #43417) [Link]

> With the current setup (feature development done on a long-lived stable branch), if you are
> developing on a bleeding edge system, you already have the problem that the version on
> that system is not the same as what is on older distros - you are developing against
> GTK+ 3.22, say, but a target system might be running GTK+ 3.14. But it's very hard to
> know what features and behavior changes you are depending on until some user running
> with GTK+ 3.14 reports a bug

As someone who has maintained code for some years which is intended to keep working on older versions of GTK+2 and/or GTK+3 as well as recent versions, I have to say that I think GTK+ has been good in its documentation in indicating when new stuff arrived, and GTK+3 provides the means to tailor deprecation warnings to the targeted earliest GTK+ version intended to be supported, with the GDK_VERSION_MIN_REQUIRED macro. If you stick to the C API you are unlucky if you meet breakage not arising from the normal unintended bugs you get from time to time and which will be fixed.

With GTK+3 the problem has been when you try to use your own theming, which still breaks regularly with new minor versions, and in the early years if you tried to develop with language binding using gobject-introspection, which was also unstable for a period after it came out (it is however much better now).

Flatpak

Posted Sep 29, 2016 19:21 UTC (Thu) by swilmet (guest, #98424) [Link] (20 responses)

In the future, if a LTS distro ships only GTK+ <= 4 but you want to use GTK+ 5 and still be able to install that app on the old distro, you can use Flatpak or other container systems.

Flatpak

Posted Sep 29, 2016 19:27 UTC (Thu) by johannbg (guest, #65743) [Link] (19 responses)

Why would the distribution bother to ship the application in the first place if it's available as an container?

Flatpak

Posted Sep 29, 2016 19:51 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link] (18 responses)

> Why would the distribution bother to ship the application in the first place if it's available as an container?

Flatpak is really a container at this point

http://flatpak.org/faq.html#Is_Flatpak_a_container_techno...

OP is talking about users using the application. Not just distributions. Distributions might not ship it but they could make it more readily accessible for a curated pool. GNOME Software supports flatpak and it could be pretty seamless.

Flatpak

Posted Sep 29, 2016 22:59 UTC (Thu) by johannbg (guest, #65743) [Link]

The scenario he describes is already here.

On F24 you have libreoffice 5.1.5 but if you visit the libreoffice website the first thing that happens is your offered to download the libreoffice 5.2.2 <-- release which probably is newer release than is being shipped in every distribution with perhaps the exception being Arch.

The main download correctly selects rpm packages for me but on that download page it is also available as an deb package, flatpak and a snap ( but not appimage ) and for other OS.

As an end user I get thrown in the terminal no matter which option I chose.

If I chose the rpm file, I have to first untar it, then go through the readme file for direction on how to install it, then open a terminal and finally install it and pray it wont conflict with current installation and cause me dependency hell on updates/upgrates etc the usual stuff everybody is familiar with.

If I chose flatpak or snap image I'm again thrown to the terminal, first to set the environment to be able to use it.
( which means not everybody will be able to use either since not all distribution would have it pre-installed or support flatpak or snaps et all )
Then run from the terminal via "flatpak run org.libreoffice.LibreOffice" or "/snap/bin/libreoffice" or at best find the *correct* icon to double click in the desktop environment since it was already installed.

This highlights the sad truth that download options the libreoffice community is so eager to push on their website visitors as soon as they land on their page is completely useless for novice end users ( atleast on the linux platform ) unlike the upstream krita community which offers itself only as an appimage and end user just have to download it, give execution permission, double click it and voile. ( It probably would only take a minor patches to desktop environment to make it so that the end users just have to double click it and click run )
All which can be done from within the desktop environment. ( I urge people to make their own comparison of the two [1][2] )

Anyway once application becomes readily available in container format ( whatever it might be appimage, flatpak,snap etc ) and offered in app market of some sort ( not necessary but better ) there really is no point in distribution carrying them anymore because a) it would be wasting community resources in doing so and b) if that container format sets up an desktop icon ( launcher ) for the end user it would only confuse him if the application was previously installed.

1. http://www.libreoffice.org/download/libreoffice-fresh/?ve...
2. https://krita.org/en/download/krita-desktop/

Flatpak

Posted Sep 29, 2016 23:49 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link] (16 responses)

> The scenario he describes is already here.

Not really. Barely any upstream software offers any of these software under distribution neutral formats and support for them is still pretty weak. When the latest GNOME Software and builder gets into more users hands, the consumption and development story for flatpak better. Whether upstreams adopt it is an open question. GNOME, Endless etc is using it heavily but other than a few isolated examples like Libreoffice, we are just getting started.

Flatpak

Posted Sep 30, 2016 8:30 UTC (Fri) by johannbg (guest, #65743) [Link] (15 responses)

I dont think GNOME Software and builder will miracle save or hurdle flatpak for adoption so we have yet to see what comes out of the container image wars.

On one hand you have Red Hat vs Canonical with their flatpack and snaps which aren't truly cross distributional and on the other you have appimage and perhaps orbital apps ( thou I dont see much future for that project ).

May the best app market win...

Flatpak

Posted Oct 1, 2016 14:11 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link] (14 responses)

> I dont think GNOME Software and builder will miracle save or hurdle flatpak for adoption so we have yet to see what comes out of the container image wars.

You seem to be in good agreement with me - "Whether upstreams adopt it is an open question."

> flatpack and snaps which aren't truly cross distributional

Assuming you mean flatpak in the first thing, I have no idea why you think either aren't cross distributional. Btw, appimage doesn't have any sandboxing. That isn't quite the same thing.

Flatpak

Posted Oct 2, 2016 10:07 UTC (Sun) by johannbg (guest, #65743) [Link] (13 responses)

"Assuming you mean flatpak in the first thing, I have no idea why you think either aren't cross distributional."
flatpak and snaps have prerequisite to be able to work on the end user system hence as such solutions they aren't cross distributional.

Do you think you will be able to use flatpaks and snaps on ChromeOS out of the box?
If your answer is well that depends entirely on ChromeOS shipping and setting the environment up for the end user to be able to do so ( or the end user having to do so himself if it is not ) then the solution ( from my pov ) is not cross distributional.

With appimage there is no such prerequisite. Nothing needs to be setup, shipped thus maintained by the distribution or the end user to be able to run the application other then granting it permission to do so and run it.

It however starts having prerequisite if you are going to use any sandboxing solution surrounding it ( systemd/firejail/bubblewrap etc ) or the appimage updater.

Flatpak

Posted Oct 2, 2016 13:16 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link] (9 responses)

> Do you think you will be able to use flatpaks and snaps on ChromeOS out of the box?

ChromeOS is designed to run nothing but web apps out of the box. It is by no means a regular Linux distribution.

Flatpak

Posted Oct 2, 2016 17:12 UTC (Sun) by johannbg (guest, #65743) [Link] (8 responses)

Just swap it out for any distro that provides an desktop but decides not install or provide these prerequised that are required to run flatpak or snaps

Flatpak

Posted Oct 2, 2016 17:22 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link] (7 responses)

> Just swap it out for any distro that provides an desktop but decides not install or provide these prerequised that are required to run flatpak or snaps

This sounds largely theoretical. You can't run appimage on any distro that doesn't satisfy the pre-requisites of appimage either.

Flatpak

Posted Oct 2, 2016 21:32 UTC (Sun) by johannbg (guest, #65743) [Link] (6 responses)

Actually I think you can all the way down to the kernel but at that point it would just be called livecd ;)

Flatpak

Posted Oct 3, 2016 2:31 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link] (5 responses)

> Actually I think you can all the way down to the kernel but at that point it would just be called livecd ;)

Again, you can't pull an arbitrary appimage off an upstream site and except it to bundle say Xorg. There are definitely pre-requisites. Snap and Flatpak isn't really any different.

Flatpak

Posted Oct 3, 2016 6:18 UTC (Mon) by johannbg (guest, #65743) [Link] (4 responses)

Why cant I expect it to bundle x-org?

You do realize novice end users expect things to work for them right?

They don't care how it works or if one solutions is more technically correct than the other, they just care that it does work for them and if that requires it to bundle x-org into the application image then that's what needs to be done.

And the fact is app images work out of the box with released, stock installation of Fedora/OpenSuse/Debian etc if not all top 10 distro's. used today while atleast currently flatpak and snaps dont.

On top of that last time I checked flatpak depended on systemd which could excluded top linux distro's out there ( which are all Debian or Debian based distributions and those have no guarantee of being systemd only ).

As things stand now flatpak and snap need more pre-requisites on the host system than app image does and app image can be made fully self sustainable whether you or I expect it or even it was smart to do so which means app image have true portability as in you can save application(s) to usb stick, stick it to linux mint,debian,opensuse etc and double click it and it will run or delete the application image and it's gone just like end users can move an .app bundle to the trash in os-x the only complain people will probably hear from end users is that it might be slow to start.

All these solutions will need to bundle all the libraries that may be required for any of the platforms they want to support to truly make applications be portable between different machines with different distributions and versions.
That means that libraries may be already present on the host thus is being duplicating on disk and in memory but if people start removing those duplicates ( which could be quite easily achieved with at least app images ) people end up getting different end results on different hosts using different distributions ( you will lose the portability of the application images) and at that point people are better of just using the distributions provided application.

Flatpak

Posted Oct 3, 2016 11:04 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link] (3 responses)

> Why cant I expect it to bundle x-org?

The answer should be very obvious. If not, go ask any upstream if they are willing to do that.

> On top of that last time I checked flatpak depended on systemd

Feel free to check again.

Flatpak

Posted Oct 3, 2016 11:24 UTC (Mon) by johannbg (guest, #65743) [Link] (2 responses)

"The answer should be very obvious. If not, go ask any upstream if they are willing to do that."

This was not question if they should or would it was a question if they could.

"Feel free to check again. "

Really...

This is from their own FAQ page [1]

"Is Flatpak tied to systemd?

Somewhat. We currently rely on systemd (in particular, systemd user sessions, ie. systemd --user) to set up cgroups for our sandbox."

In anycase this discussion is leading nowhere.

My conclusion after looking into this is upstreams that are genuinely considering portability and end user usability should be looking into appimages not the other solution that exist out there but ymmv.

1. http://flatpak.org/faq.html#Is_Flatpak_tied_to_systemd_

Flatpak

Posted Oct 3, 2016 11:33 UTC (Mon) by mjg59 (subscriber, #23239) [Link]

> This was not question if they should or would it was a question if they could.

How are you going to package an application that, on some distributions, must be setuid root in a package format that's based around it being installable as an unprivileged user?

Flatpak

Posted Oct 3, 2016 12:07 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]

> This was not question if they should or would it was a question if they could.

Umm, no. I don't care about whether they theoretically could. I care about whether they realistically would and the answer is no.

> Really...

Yep.

https://github.com/flatpak/flatpak/releases

"Dropped requirement for systemd --user."

> In anycase this discussion is leading nowhere.

Agreed.

Flatpak

Posted Oct 2, 2016 16:23 UTC (Sun) by zlynx (guest, #2285) [Link] (1 responses)

So appimage somehow works no matter what the graphics and sound settings are?

I doubt that.

I bet that if the system isn't X graphics the appimage falls over and cries.

That looks like prerequisites to me, same as the others.

Flatpak

Posted Oct 2, 2016 19:06 UTC (Sun) by johannbg (guest, #65743) [Link]

In the case of app images the provider of the image itself is responsible for what assumption he makes is available on the client system which is probably based on specification (desktop), the appimage community best practices or an app market policy.

Appimages are just ISO9660 which has been specifically designed to run an application and as such can be easily extend beyond that ( and that means include a full blown x server if that's what's required ) with the only question being where are you going to draw the line between an live cd and an app image.

Appimage being an ISO image you can simply mount it as such to inspect what's on it.

Flatpak

Posted Oct 2, 2016 22:59 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

> Do you think you will be able to use flatpaks and snaps on ChromeOS out of the box?
This might be not impossible. Crouton allows to run a full-scale distro in a chroot, but it requires developer mode to be enabled. But now it looks like the sandbox in ChromeOS is pretty capable of running arbitrary code.

GTK+, version numbering, and long-term support

Posted Sep 29, 2016 17:45 UTC (Thu) by flussence (guest, #85566) [Link]

I think it's fair to say GTK+ development hasn't resembled Semantic Versioning at any point after the GTK+2 series. The current scheme is more something long-time Python users would understand: version x.y.z is not stable unless and until a version with higher x exists.

GTK+, version numbering, and long-term support

Posted Sep 29, 2016 23:32 UTC (Thu) by chrisV (guest, #43417) [Link] (1 responses)

> To be fair, though, releasing x.0 versions that were unstable was certainly not the intent of the scheme announced.

It was the intent of the scheme announced: "Each 6 months, the new release (Gtk 4.2, Gtk 4.4, Gtk 4.6) will break API and ABI vs. the release that came before it". This included Gtk 4.0, which was then proposed to be the first unstable development release of the 4.x series. With the latest proposals, there seems to have been some movement back from that degree of six-monthly breakage.

> Furthermore, any features deprecated in one x.0 release will be removed in the following x+1.0 release. This is another area where
> GTK+ has not historically had a strict policy, so stating and adhering to a regular deprecation formula will no doubt please many
> outside developers

It doesn't please me. I prefer the current arrangement whereby the deprecated code is carried forward albeit with deprecation warnings (which you can switch off with the GDK_VERSION_MIN_REQUIRED macro (which despite its name covers GTK+ as well as GDK). You don't want to rewrite any more of your code every 2 or 3 years than to need to.

More generally I suspect that the 2 to 3 year churn for stable releases, with the attendant removal of deprecated code every 2 to 3 years, will be too much for some projects. I still use a few applications (claws-mail and gnucash) which I do not believe have any clear plans to move to GTK+-3, let alone its successors. Firefox has only recently been usable reliably with GTK+-3 in place of GTK+-2.

But time will tell, as in all things.

> That puts some indirect pressure on the project to release a stable y.0 release once the development version's minor
> number reaches .98, as Sébastien Wilmet noted on the GTK+ development list.

What is wrong with ... 4.96, 4.98, 4.100, 4.102, if required? These aren't decimals.

GTK+, version numbering, and long-term support

Posted Sep 30, 2016 8:34 UTC (Fri) by swilmet (guest, #98424) [Link]

> What is wrong with ... 4.96, 4.98, 4.100, 4.102, if required? These aren't decimals.

As ovitters explained in the first comment: "We already use x.uneven y.90+ to indicate beta/rc quality so using something similar for the minor should be pretty recognizable."

See the GNOME release schedule:
https://wiki.gnome.org/ThreePointTwentyone

GNOME 3.21.1 -> GNOME 3.21.4: unstable/alpha releases.
GNOME 3.21.90 and 3.21.91: beta releases.
GNOME 3.21.92: rc release.
GNOME 3.22.x: stable releases.

So the GTK+ 3.9x releases can easily be recognized as beta releases. GTK+ 3.100 less so.