Hi, if your application depends on both GTK 4 and WebKitGTK, this announcement is important for you.
I failed in my goal to prepare a stable GTK 4 API for WebKitGTK in time for GNOME 43 and WebKitGTK 2.38. I am finally on track to stabilize the API for GNOME 44 and WebKitGTK 2.40. There will be several changes:
The pkg-config API version will change from webkit2gtk-5.0 to webkitgtk-5.0 as I’ve removed more vestiges of the legacy WebKit2 branding
This will be moderately disruptive when WebKitGTK 2.40 is released in March next year alongside GNOME 44. The problem is distros will release WebKitGTK 2.40 to stable users, but it will contain a different GTK 4 API and ABI than WebKitGTK 2.38. Applications that use GTK 4 will all need to be patched to use the new API version and then recompiled. This will be annoying for stable distros, but my expectation is it should be manageable because there are only a few such applications. In GNOME core, that is only gnome-builder and gnome-initial-setup. These should both be quite easy to handle. Distros will need to bundle all these updates together so that everything that depends on WebKitGTK for GTK 4 will be updated in tandem with WebKitGTK 2.38 → 2.40 to avoid breaking users.
Does that mean the Gtk 4 API will not be available in the gnome 43 flatpak sdk/runtime? Even in its current non-stable form. Since it is already part of master I had high hopes it would also make it into the 43 release.
It will be available in the 43 SDK, but since it is unstable you need to be aware that API/ABI will change during the life of the 43 SDK, specifically around the time of the GNOME 44 release next March when WebKitGTK 2.40.0 is released. The current API version (webkit2gtk-5.0) will disappear and be replaced by the new API version (currently webkitgtk-5.0, but I’m toying with increasing to -5.1 or something). All apps that depend on it will break when this happens. So please use it very carefully.
Is it really necessary to break Apps with minor updates to a runtime/sdk? As far as I know there is no way to pin an app to a exact version of a runtime. So even if one was quick to adapt to changes, there would almost certainly be a time frame in which apps just break. What would be so bad about committing to a master snapshot for 43 and only updating to 2.40 in the 44 runtime/sdk?
Anyway, thanks for the heads up and your work on webkit.
I typed up a “sorry, but yes” answer but, actually, due to the way we build WebKitGTK, it’s possible to use a different version of WebKitGTK for GTK 4 than for everything else. So we can freeze the GTK 4 element on 2.38.x, while allowing the GTK 3 versions to continue to receive updates. This seems like a good compromise.
FWIW, I think it would be prudent to bump the version number to 5.1 along with the rename, to reduce support effort a bit. It’ll make it more clear that they’re different versions when a dev’s eyes are glazed over wondering why “5.0” was not found when it’s clearly “right there!”.
Having two different “5.0” versions complicates my life as a distro packager a little bit, but at least I have a heads up to plan ahead for the change.