“Gtk 4.0 is not Gtk 4”

… and that’s OK.

This morning in Toronto, many GNOME developers met to kick off the GTK hackfest.

The first topic that we discussed was how to deal with a problem that we have had for some time: the desire to create a modern toolkit with new features vs. the need to keep a stable API. Gtk 3 has seen a very rapid pace of development over its lifetime and we have a much better toolkit than we started out with. Unfortunately, this has often come with the cost of less-than-perfect API stability. In addition, the need to keep the API mostly stable for years at a time has somewhat slowed the pace of development and created a hesitation to expose “too much” API for fear of having to live with it “forever”.

We want to improve this, and we have a plan.

Everyone present for the discussion was excited about this plan as the best possible way forward, but it is not yet official. We will need to have discussions about this with distributors and, particularly, with the GNOME release team. Those discussions are likely to occur over the next couple of months, leading up to GUADEC.

We are going to increase the speed at which we do releases of new major versions of Gtk (ie: Gtk 4, Gtk 5, Gtk 6…). We want to target a new major release every two years. This period of time was chosen to line up well with the cadence of many popular Linux distributions.

The new release of Gtk is going to be fully parallel-installable with the old one. Gtk 4 and Gtk 3 will install alongside each other in exactly the same way as Gtk 2 and Gtk 3 — separate library name, separate pkg-config name, separate header directory. You will be able to have a system that has development headers and libraries installed for each of Gtk 2, 3, 4 and 5, if you want to do that.

Meanwhile, Gtk 4.0 will not be the final stable API of what we would call “Gtk 4”. 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. These incompatible minor versions will not be fully parallel installable; they will use the same pkg-config name and the same header file directory. We will, of course, bump the soname with each new incompatible release — you will be able to run Gtk 4.0 apps alongside Gtk 4.2 and 4.4 apps, but you won’t be able to build them on the same system. This policy fits the model of how most distributions think about libraries and their “development packages”.

Each successive minor version will be growing toward a new stable API. Before each new “dot 0” release, the last minor release on the previous major version will be designated as this “API stable” release. For Gtk 4, for example, we will aim for this to be 4.6 (and so on for future major releases). Past this point there will not be disruptions; this “stable API” will be very stable. There will certainly not be the kind of breaks that we have seen between recent Gtk minor releases.

In this way, “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).

The first “API stable” version under this new scheme is likely to be something like Gtk 3.26.

Applications authors will have two main options.

The first option is to target a specific version of the Gtk API, appearing once per two years, that stays stable forever. Application can continue to target this API until the end of time, and it will be available in distributions for as long as there are applications that depend on it. We expect that most third party applications will choose this path.

If two years is too long to wait for new feature, application authors can also choose to target the unstable releases. This is a serious undertaking, and requires a commitment to maintaining the application during a two year period, and keeping up with any changes in the toolkit. We expect that GNOME applications will do this.

Third party application authors can also follow the unstable releases of Gtk, but we encourage caution here. This will work for GNOME because if a single maintainer disappears, there will be others to step in and help keep the app up to date, at least until the next 2 year stable release. This approach may also work for other large projects that are similar to GNOME. With individual app authors, life can change a lot during two years, and they may not be able to make such a commitment. Distributions may decide that it is too risky to ship such applications (or update to new versions), if they use the unstable API.

In general, we feel that this approach is the best possible combination of two distinct and valid desires. Gtk users that have been asking for stability will get what they need, and the authors of Gtk will get additional freedom to improve the toolkit at a faster pace.

… now let’s see what we discuss this afternoon.

40 thoughts on ““Gtk 4.0 is not Gtk 4””

  1. Oh, man, this is just fodder for those who like complaining.

    It’s also for the best.

    Gtk+ 3 took a while to mature, till around 3.10 really, but it’s better than ever now.
    So telling people that the latter point releases are where it’s at makes sense.

    Developing against 3 < 3.10 was just irritating and a waste of time. Being able to target a specific runtime while catching up should work nicely.

    And you guys get to play all you want without worrying.

  2. I’m sorry, but you can’t be serious? Please think it through – all the way though – You will loose me as a developer – thats for sure. Don’ worry though, I am small. I only have about 20 projects.

    P.S. What is the name of your Doctor? I would like to have a chat with him.

  3. Will be GTK 4 the future sucessor of .NET Framework? Because .NET Framework practically haves the same development process that haves multiple versions and most of then are not used (only .NET Framework 2.0 and 3.5 is widely used that 4 and 4.5 versions on Windows due to Mono compatibility).

    Unfortunately, this choice will mean a defragmentation of the users of GTK, and instead of accelerate the adoption of modern versions of GTK, stacks on older versions such like .NET Framework.

  4. The title of this post sums up why this is going to be incredibly confusing.

  5. 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?

  6. I think everyone is glad that the GTK+ team is looking into solutions for the problem of the restrictiveness of having a strict API/ABI and the need for a stable API that consumers can use.

    However, this proposal only works if the sole consumers of GTK+ are applications or if everyone only uses Flatpak. The workflow you’ve outlined works reasonably well in that case. Distros ship all stable series and applications upgrade whenever they want or can.

    In practice, libraries do use GTK+ (such as GStreamer, WebKit-GTK+, gtkmm, etc) and having multiple APIs and ABIs to support would explode the support matrix for such libraries and in the end for distros. From my experience as a distro packager and a GStreamer contributor, I’ll list a bunch of scenarios that demonstrate this.

    * GTK+ 4.2 (unstable) is released. GStreamer adds support for it in the gstgtkglsink and gstgtksink plugins with #ifdefs and a configure option. However, distros can’t ship this support since it’s a compile-time option (no parallel installable plugins), so applications that use these plugins can only use GTK+ 3 (stable).

    * GTK+ 4.6 (stable) is available. GTK+ 5.2 (unstable) is released. WebKit-GTK+ now has compile-time support for 3, 4, and 5. The maintainers swallow the bitter pill and split their library naming to allow parallel-installation of WebKit-GTK+ built with each version. But because the GStreamer gtksink plugins can only use one version of GTK+ at a time and many applications still haven’t been ported to GTK+ 4, distros can only ship the least-common-denominator support. But GNOME applications *require* GTK+ 5, and now distros are forced to ship old versions of GNOME Web and Evolution till every application that uses WebKit-GTK+ supports GTK+ 5. In the worst case this happens every 6 months with every API break.

    * Same case as above, but GStreamer finds a way to parallel-install plugins. WebKit-GTK+ also supports parallel-installation of libraries. Applications have compile-time selection of all three. However, most applications stick with GTK+ 3 because they don’t have the manpower to keep up with API changes. Sadly, only the newest GTK+ has fixes required for proper Wayland integration. Will the GTK+ maintainers backport these fixes to older “stable” releases? When is a GTK+ stable major version abandoned? Having the wrong answers for these will alienate developers.

    * Library X adds support for parallel-installation, but library Y doesn’t. Sadly, library X depends on library Y, so their parallel installation efforts go to waste and distros have to ship the lowest-common-denominator.

    As you can see, this API/ABI scheme completely screws over libraries and by extension distros and even the GTK+ team in terms of maintenance. Not every library is going to agree to split their libraries, and most applications aren’t going to keep up with the latest GTK+ API/ABI breaks. I think this solution is completely untenable, and every distro maintainer I’ve talked to has been horrified by this proposal. :-)

    It is rude to criticize without alternate proposals, so here’s one. Have GTK+ be built into two libraries: libgtk3 and libgtk3-unstable. The former *always* maintains API/ABI stability, and the latter breaks it with every release (with the appropriate soname bumps). When a portion of the API in libgtk3-unstable is deemed “stable”, it moves to libgtk3. I think this would solve the problem of API instability not being properly communicated to developers, and would allow new API to evolve as needed.

    This also means that the GTK+ team has to live with API/ABI being available “forever” in the stable library, but this is the same requirement as every other library in the Linux ecosystem. It would be great to have a list of reasons why this doesn’t work for GTK+ so we can address those.

  7. Instead of suffering garbage, would do fix jambs display elements. That window stretches across two screens with one line of text, or to a place of scrollbars, the more that. And it comes from the very inception GTK3. No, instead we suffer garbage and cut out features of Gnome, Gnome applications and breaking compatibility with other opensoftom. however, it is not treated, for CSS, consisting of some crutches.

    Let bury better themselves and their gtk3.

  8. Hey there,

    I’ve read many comments on this proposed versioning scheme in a few places around the web, and I’m sorry to say that I couldn’t find people who liked this idea.

    The main concern is that your use of version numbers goes against anything people ever seen, and as such, is not intuitive, a bit misleading and creates far too much confusion.

    While the idea of providing truly stable GTK releases makes sense, the proposed way clearly needs to be rethought, and in that process, community feedback has to be considered.

    It’s clear that you’re trying to achieve two main goals here:
    * Be able to make breaking changes to GTK on every new GNOME release, which happens around every 6 months.
    * Be able to offer truly stable releases of GTK, and a clear target for third-party developers.

    As far as I can tell, this proposal doesn’t fulfill the second part of the second point.

    So here, let me take a stab at it: let’s use the fact that the different GTK versions will be separated into different packages, and just use semantic versioning (“semver”) for each of the versions separately. The package name and version scheme can be GTK(ver) X.Y.Z for public releases, and GTK(ver) X.Y.Z-pre.W for development releases. (“pre” can be any other identifier; “dev”, “alpha”, “beta”, “rc”, etc.)

    Following this scheme, GTK4’s first unstable development release will be GTK4 0.1.0-pre.1. When the next GNOME is released alongside GTK4, it will become GTK4 0.1.0. On a bugfix patch that may follow, it will be tagged GTK4 0.1.1. And finally, when the API is truly stable, it can be declared GTK4 1.0.0. Shortly after that, GTK5 0.1.0-pre.1 will be branched. At this point, on a bugfix release, GTK4 will be tagged as GTK4 1.0.1. If a non-breaking feature release happens to land for GTK4, it can simply be tagged GTK4 1.1.0. Regardless of GTK4 and its particular version, GTK5 0.1.0 will be released as part of the following GNOME release, and so on and so forth.

    This particular proposal has quite a few advantages over the current one:
    * Anybody can understand the stability status and what to expect from each specific version of GTK without ever having to look up information about it. This includes automated scripts. As a simple example, “GTK5 0.3-rc.2” is clearly the second release candidate for of the third bi-annual release of GTK. The fact that its version starts with 0 means that it’s not yet stable.
    * Third party developers can have a clear target when they require forever-lasting stability. (they simply opt for the latest GTK which has a 1.* release)
    * GTK developers have a great flexibility when it comes to clearly organizing development release cycle. For instance, it would allow the proper tagging of any kind of release, such as differentiating between development versions (-dev) and release candidates (-rc).

    All in all, discussions need to be had.

  9. I don’t dislike this idea, an LTS style GTK could work but please . . . PLEASE! . . . don’t make GNOME apps and Third-Party apps depend on different structures. This would just be a different type of headache.

    If GNOME apps want to support the “non-LTS” versions then great but they should also support the “LTS” releases as well that way if a distro chooses the Stable and the majority of Third-Party apps choose the “LTS” then we won’t have such a mess to deal with.

    Epiphany is a great example. Epiphany (aka GNOME Web, bad name btw) only gets new updates in distros when GNOME releases new versions so if 4.0 and 4.4 aren’t installable side by side then it means people who use a distro that selects 4.0 won’t be able to get any updates for apps that GNOME makes.

    Please don’t do that.

  10. I’m seriously confused, here. So if I’m writing a new app, you’re basically saying that I should ignore new Gtk+ releases until .6 or so, because they’re not actually considered suitable for use yet? That despite having made a .0 release, I should expect to be chasing API/ABI breaks for a year or so if I decide to use it?

    Isn’t that the exact same problem KDE had with 4.0 and 5.0… fighting with the entirely natural assumption of developers that if you’ve made a .0 release, it’s expected that it’s ready for everyone to use?

    Maybe I’m misunderstanding you… but this post comes across as a *major* deterrent to using Gtk+…

  11. Sorry, I don’t buy it. The main problem is that this scheme is difficult to follow, because it is so different and unintuitive. Furthermore, you have no clear indication when something will be actually stable.

    The Semantic Versioning (http://semver.org/) scheme is easier to digest and follows intuitive rules. There you have a clear indication when there are API / ABI breaks. If that means GTK starts getting into major version 456, so be it. No misrepresentation. No ambiguity.

    Alternatively, if you want to have an continually unstable GTK, call it GTK 5.x and leave GTK 4.x as the super-boring and stable release. Once GTK 5 stabilizes, call it GTK 6 and leave it alone. New unstable development would then go in GTK 7.x.

    The above odd/even versioning form is an adapted form of Semantic Versioning, where odd numbers are explicitly unstable, and even numbers are explicitly stable.

  12. Hi Allison,

    As an alternative, may I please suggest that the Gnome project adopt Semantic Versioning (http://semver.org/) for GTK releases?

    I know a lot of people — our organisation included — who would not even start a port to a new version of a huge library like GTK+ without some understanding of what sort of ABI stability can be expected. Under you proposed scheme, we (and many other developers) wouldn’t even bother looking at GTK+ 4.x before GTK+ 5.0 had been released (and some sort of ABI stability had been established).

    The Qt and KDE teams seem to manage to provide excellent library ABI stability over multi-year release cycles, even with the much greater challenge imposed by using C++. Surely it must be possible for GTK+ to do the same.

    Or at least, please use semver and ldconfig versioning rules. I don’t mind installing GTK+ 246.0.0 if that’s what’s necessary.

    Thank you for all your hard work on GTK+!

  13. I think the problem is the name. You should name it gtk-experimentel and then release gtk 4.0 if it is ready and API stable.

  14. its very ambitious, but, doe programs go to GTK4 GTK5 means that not all programs gona follow, so generally gnome stuf get the pace?

    at the end you get some depency hell?

  15. Just a little input from an occasional Gtk user… I’m a bit worried that you want to break compatibility so often (with each minor version).

    You say an application could target a specific version, e.g. 4.2, and leave it at that. It would not break, but it will also not receive new features. One great thing about the “old” Gtk (2.x) was that it was incredibly backward compatible. I wrote a little tool many years ago in PyGtk, and it ran on (already then outdated) Gtk 2.12 I think, but it also ran on every version up to Gtk 2.28 without changes. It benefited automatically from new features, new themes, bugfixes, and so on. I tried it the other day, and it even runs on current Ubuntu. I never managed to produce anything for Gtk 3.x, because it moves so fast that my projects break before I can fix them (I don’t have much time to work on these side-projects, but I’d like them to be polished, and to run on multiple Gtk/OS versions – bleeding edge at home and whatever the old CentOS version at work has.)

    I realize it is a bit more work for you developers, but the best thing for consumers of the libraries would be to only make backward compatible changes as much as possible. Only add to the library in minor versions, never remove (only deprecate). So a program that is compiled with Gtk 4.0 would be guaranteed to run with 4.2, 4.4, .. and so on.

    You would be able to break at 5.0, and since you want major versions every two years this is a lot more frequent than it used to be, so you can remove cruft faster. However, breaking changes are always bad, and “break-the-world” updates always leave a large part of the user base behind (think Python 3, Gtk 3, …).

    [ Here is a crazy idea (independent of the above): Always call the current major version the same thing, say Gtk3. If there is absolutely unavoidable breakage, instead of creating Gtk4 and waiting for apps to update, freeze the old version at Gtk3-2017 and call the new version Gtk3 :-). That way, behaving apps (that don’t use deprecated symbols) would continue to run, and non-behaving apps could either be compiled to a specific version, or get to run with a GTK_VERSION / LD_LIBRARY_PATH variable. I don’t know how feasible this would be, it’s just something that came to my mind. But it would be a solution to the problem that major versions often leave people behind. ]

    Finally, I don’t understand why you say you’d be able to install apps targeting separate Gtk versions in parallel (4.2, 4.4, …), but you won’t be able to build them on the same machine. Do you mean these different runtimes would be using something like desktop app containers? Or each app would package their own dependencies?

    I think a better way would be to install every installation in its own root, e.g. /usr/lib/gtk-4.2/… and symlink the current best versions to /usr/lib. You could even make distributions with known-good combinations of glib, gtk, …, for example /usr/lib/gnome-suite-2017-3/. This would also mean you’d be able to easily compile an app for 4.0 (by setting include and library paths appropriately) so that it would run with every 4.x without recompilation. Also, I’ve always found it rude for a program to clobber /usr/bin, /usr/lib, and so on.

    Sorry for the lengthy write-up :-) keep up the good work! Versioning scheme aside, I’m curious to see what version 4.x will bring.

  16. Hi Allison,

    I’m so happy to read this. I’m delighted to see you talk about this issue and the way you’re addressing it is very good in my opinion.

    GTK is a wonderful toolkit to work with. Our two concerns were that it might veer too much towards GNOME Shell (i.e. that GTK dialogs and widgets might not look “native” or properly “integrated” in other desktop environments) and that GTK3 was a moving target so it was difficult to ship GTK3 apps to different distributions (at the moment we need to target GTK 3.14 and GTK 3.18 internally, while supporting GTK 3.20 for Fedora and Arch users for instance).

    We’ve seen you address the first point a few times.

    And this post today is music to my ears. I hope it will boost your development. On our side it would definitely help a lot with stability and reliability.

  17. Ok, first off, thanks for letting everybody know at an early stage.
    I can imagine why marketing might want faster major revisions, and don’t like the 3.9x kind of versioning much myself.

    But this proposal makes it impossible to see (from the version number alone) whether the final iteration of the Gtk API has been reached. Could be 4.6, could be 4.8. Next time around it might be 5.12.

    So my suggestion would be to bump to x.100 and pronounce it “Gtk400”, for example. Avoids confusion with any previous “Gtk4 dot ” in cases where this differentiation matters.

  18. I won’t judge this plan and idea, this is up to the developers only and maybe a good way for Gtk to gain more stability and users. But want I consider very bad is the numbering, “x.0” or 0-Release means stable, nothing else. GCC has done a similiar[1] thing and it totally bewildering. Instead of just critizing this idea I would suggest to think about other possible ideas to numbering or marking release. My first idea:

    Gtk-stable-2.24
    Gtk-dev-3.20 # current release
    Gtk-dev-3.22
    Gtk-dev-3.24
    Gtk-stable-3.26
    Gtk-dev-4.0
    Gtk-dev-4.2
    Gtk-dev-4.4
    Gtk-stable-4.6

    It would be linear, easy to understand and honest! Maybe other people have even better ideas.

    [1]https://gcc.gnu.org/develop.html

  19. — But want…
    +++ But what…

    Other suggestion, I even like this more, from Gtk4 ongoing:
    Gtk4-0.1 # this is an officiall release, but just for six months
    Gtk4-0.2 # this is an officiall release, but just for six months
    Gtk4-0.3 # this is an officiall release, but just for six months
    Gtk4-0.4 # this is an officiall release, but just for six months
    Gtk4-1.0 # rock stable for ages
    Gtk4-1.0.1 # small bugfixes
    Gtk4-1.1.0 # handy new features, but still rock stable for ages
    Gtk5-0.1 # this is an officiall release, but just for six months

    The numbers below 1.0 still indicated an ongoing development, the numbers above indicated stability.

    PS: You can even to crazy thing (would avoid it) and bump Gtk4 to Gtk4-2.0.0, it has to be still rockstable, but may add crazy things like “Wayland-Support” or a new supported operating-system.

  20. Using 4.6 and avobe may will be confusing, When start to develop against?

    While this is good because will push GTK development to new levels, may we need to skip 4.0 and go to 5.0, to use odd numbers for unstable API, when it reaches stable API switch to 6.0, here we can use 6.1 for testing bug fixed release and 6.2 for stable bug fix release; same could unstable odd versions, say 5.1 could be like Sid in Debian and 5.2 like testing for next stable release. Micro version for unstable could be for new versions, no bug fixed necessarily.

  21. I’m all for speeding up development and breaking the ABI often. However, why not just bump the major release every six months instead and have every fourth release be an “LTS” release? It’s not like we’re running out of version numbers any time soon, and if you’re going to bump the soname anyway why not just let it follow the version number?

  22. This seems like a well though out plan! Though, how will Glade support this release style? Will I be able to target a specific GTK+ version?

  23. Why not just let the proposed gtk 4.0, 4.2, 4.4 be actually called gtk4.0alpha1, alpha2, beta1, etc. and the proposed gtk4.6 be the actual 4.0? To avoid confuse people and to keep with the conventional practices? You can break anything from alpha to beta and people will know that is expected.

  24. It seems like a great step forward, but I’m worried about version proliferation. We’re gonna quickly wind up with five different versions of GTK+ installed on the system at once, each with a different theme. I would seriously consider using a three year cycle instead of two years, which would really help with this without making app authors wait too much longer for the new stuff.

  25. Stabalize Gtk3 and do just this!

    GNOME already suffers from the split between Gtk2 and Gtk3. A lot of applications doesn’t look similiar in behaviour and look. Now Gtk4 splits practically all GNOME-Applications away from every other application, which is using Gtk3 (assuming the stuff like Inscape, Gimp or the new Firefox-Sucessor will be ever ported to Gtk3).

    We will never again have a full desktop environment which a great number of applications with the same toolkit. An this also doesn’t fix the issues around themes, basically the themes will be forced to support a stable Gtk3 and an unstable Gtk4. This is a nightmare. An as developer I will always want use the newest, but as maintaining developer I want the stable thing. This is painfull decision.

    At first I thought ‘great’ this means stability, but in fact now your just splitting the desktop away from the applications, Gimp and so on will *never* use an unstable Toolkit.
    Gtk2 never suffered from this, it was stable. Gtk1 applications? All ported soon. Qt never suffered from this, it is stable.

    Do the one and only thing, the easy thing:
    Just keep Gtk3 as stable and possible and slowly extend it via third-party libraries, if something proves to be good, merge it into the next Gtk3 release and maintain it.
    Rationale : Great win with little effort.

    Gtk4? You didn’t mentioned one reason what is wrong with Gtk3 itself and cannt achived without a massive API/ABI-Break.

    Sorry. This howl split Gtk3/4 approach is flawed.

  26. Brilliant.

    GTK 1 – stable.

    GTK 2 – stable.

    GTK 3 – stable.

    Yes, why continue there in a logical manner. Change a working system!

    Go Gnomies, go!!!

    You can do it.

  27. Ehmm, do you even hear abou such things like Adapter, Facade or Decorator ?? Should be perfect tools for minor API changes… Also I would like to know do you plan more integration/relaying with/on Linux “initd” subsystem ? That would be terrible…

  28. The proposed plan states that one won’t be able to co-install, e.g., the -devel versions of 4.4 and 4.6. This will cause troubles to distributions which build from source, such as Gentoo.

  29. It will just create more mess compared to gtk2 vs gtk3. It adds a lot of burden of apps developers to port stuff over and over again to new libraries.

  30. This is a terrible idea. This just means that developers will use the latest stable version and leave it at that for two years, then re-write stuff for the next stable version.

    This doesn’t make any sense when most developers are part of the community and not employees of a corporation. They just won’t have the resources (both human and monetary) to keep up with the releases and will use the latest stable version and leave it at that, just like right now there are still projects that need GTK 2.

    Backwards compatibility should be the priority here.

    Just as an example, Windows XP apps will run pretty much perfectly in 2016, 15 years later; with little or no modifications. That’s what we should be aiming for.

Comments are closed.