Bug 245296 – [GTK] Bump GTK 4 API version to -6.0

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[Michael Catanzaro]

I'm going to suggest we bump the GTK 4 API version to -5.1. webkit2gtk-5.0 and webkitgtk-5.0 will be very different APIs, but you have to look closely to notice that the 2 is missing to see the difference. Adjusting the API version a bit will avoid this confusion when porting from webkit2gtk-5.0.

[Carlos Garcia Campos]

I would blame distros for packaging something we never released, but I understand why they did, so I'm not opposed to the change if that helps.

[Michael Catanzaro]

It's required to build GNOME 43 anyway (needed by gnome-initial-setup and gnome-builder).

[Calvin Walton]

(In reply to Carlos Garcia Campos from comment #1)
> I would blame distros for packaging something we never released, but I
> understand why they did, so I'm not opposed to the change if that helps.

The "webkit2gtk-5.0" api was released as part of webkitgtk 2.38.0, and is used (at least) by gnome-builder and gnome-initial-setup as part of the GNOME 43 release.

[Michael Catanzaro]

Alternatively: we could go crazy and use -6.0 instead, so future people won't confuse -5.1 for "GTK 5". We're already getting complaints from people confused by the similarity between -4.0/-4.1 API versions vs. GTK 4. Version numbers are cheap... might as well?

Carlos, why don't you pick -5.1 or -6.0, whichever you prefer. If no preference, then I'll go with -6.0.

[Adrian Perez]

(In reply to Michael Catanzaro from comment #4)
> Alternatively: we could go crazy and use -6.0 instead, so future people
> won't confuse -5.1 for "GTK 5". We're already getting complaints from people
> confused by the similarity between -4.0/-4.1 API versions vs. GTK 4. Version
> numbers are cheap... might as well?
> 
> Carlos, why don't you pick -5.1 or -6.0, whichever you prefer. If no
> preference, then I'll go with -6.0.

The completely unambiguous naming scheme™ would be:

   GTK3 → webkitgtk3-1.0 (or -1.1 with soup3)
   GTK4 → webkitgtk4-1.0
   GTK5 → webkitgtk5-1.0 (when GTK5 is released)
   ...and so on

We cannot change the GTK3 ones, but we can change going forward.

[Adrian Perez]

(In reply to Adrian Perez from comment #5)
> (In reply to Michael Catanzaro from comment #4)
> > Alternatively: we could go crazy and use -6.0 instead, so future people
> > won't confuse -5.1 for "GTK 5". We're already getting complaints from people
> > confused by the similarity between -4.0/-4.1 API versions vs. GTK 4. Version
> > numbers are cheap... might as well?
> > 
> > Carlos, why don't you pick -5.1 or -6.0, whichever you prefer. If no
> > preference, then I'll go with -6.0.
> 
> The completely unambiguous naming scheme™ would be:
> 
>    GTK3 → webkitgtk3-1.0 (or -1.1 with soup3)
>    GTK4 → webkitgtk4-1.0
>    GTK5 → webkitgtk5-1.0 (when GTK5 is released)
>    ...and so on
> 
> We cannot change the GTK3 ones, but we can change going forward.

...because if we are changing the API level, which goes in the soname,
we are changing the soname, and if we are changing the soname anyway,
we may as well change what's at the left of the dash character ;-)

[Michael Catanzaro]

(In reply to Adrian Perez from comment #5)
> The completely unambiguous naming scheme™ would be:
> 
>    GTK3 → webkitgtk3-1.0 (or -1.1 with soup3)
>    GTK4 → webkitgtk4-1.0
>    GTK5 → webkitgtk5-1.0 (when GTK5 is released)
>    ...and so on
> 
> We cannot change the GTK3 ones, but we can change going forward.

Yeah I considered this too. It is possible, but it's harder since we'd need to introduce a WEBKITGTK_GTK_API_VERSION variable and use it in a bunch of places. That said, it should be easier than WEBKIT_GTK_API_INFIX (the '2') was, so might be worth a try.

[Michael Catanzaro]

(Of course there would be massive confusion between webkit2gtk-4.0, webkit2gtk-4.1, and webkitgtk4-1.0, but can't do anything about that. I'm more concerned about avoiding future confusion anyway. Can't fix the past.)

[Calvin Walton]

I just noticed another issue with keeping the "5.0" api version - if a distro wants to make webkit2gtk-5.0 (from 2.38) and webkitgtk-5.0 (from 2.40) parallel installable to support an app that hasn't yet updated, then they will run into a collision where both packages will install libjavascriptcoregtk-5.0

I don't know if this is actually a problem (will an older webkitgtk work using libjavascript core from a newer webkitgtk?) but it's something to be aware of when considering alternate naming proposals, too.

[Michael Catanzaro]

(In reply to Calvin Walton from comment #9)
> I don't know if this is actually a problem (will an older webkitgtk work
> using libjavascript core from a newer webkitgtk?)

Definitely would not work.

[Carlos Garcia Campos]

GTK4 support is still work in progress, and we never meant to release it, I see we added the build option as public though.

[Carlos Garcia Campos]

I'm ok using version 6. I don't think we should align with GTK versions, I find it even more confusing and easy to break in the future. WebKitGTK is the GTK port of WebKit, webkitgtk is the name of the product and whatever goes after that is the version of the product, not the version of any of its dependencies.

[Michael Catanzaro]

Pull request: https://github.com/WebKit/WebKit/pull/4531

[EWS]

Committed 255953@main (cd4c7d74bfbd): <https://commits.webkit.org/255953@main>

Reviewed commits have been landed. Closing PR #4531 and removing active labels.

[Alberto Garcia]

So I see that API 5.0 disappeared in WebKitGTK 2.39.1 and there is now API 6.0.

What is the plan for packages that have been released in distros like Ubuntu and depend on the 5.0 API? Example: https://packages.ubuntu.com/kinetic/gnome-initial-setup

Are we going to be able to provide WebKit updates for cases like those?

[Michael Catanzaro]

(In reply to Alberto Garcia from comment #15)
> What is the plan for packages that have been released in distros like Ubuntu
> and depend on the 5.0 API? Example:
> https://packages.ubuntu.com/kinetic/gnome-initial-setup

For now this should only affect Builder and gnome-initial-setup. We'll imminently (next few days) release new unstable versions of all of these that depend on the 6.0 API. Once that's done, it will be safe to update development distros to 2.39.1.

When WebKitGTK 2.40.0 is released in March, stable distros will need to rebuild Builder and gnome-initial-setup to use the new API version.

Also note that the next few 2.39 releases will contain soname bumps for the -6.0 API. That should hopefully stop after 2.39.90 if all goes well.

[Alberto Garcia]

(In reply to Michael Catanzaro from comment #16)
> For now this should only affect Builder and gnome-initial-setup. We'll
> imminently (next few days) release new unstable versions of all of these
> that depend on the 6.0 API. Once that's done, it will be safe to update
> development distros to 2.39.1.

I'm worried about the cases where those packages ended up in stable releases by distros, hence the Ubuntu example.

In the case of Debian maybe we have time to manage this transition before Debian 12 (bookworm), but I don't know about other cases.

[Michael Catanzaro]

(In reply to Alberto Garcia from comment #17)
> I'm worried about the cases where those packages ended up in stable releases
> by distros, hence the Ubuntu example.

When WebKitGTK 2.40.0 is released in March, stable distros will need to rebuild Builder and gnome-initial-setup to use the new API version (and possibly also evolution-data-server, which has an optional dependency on webkit2gtk-5.0 that I just discovered 20 minutes ago). It's not ideal, but also not a big deal.

I know it's a little annoying, but there was no avoiding this. GNOME was not going to wait any longer to start using GTK 4, and we still have a bunch of API changes that have yet to land.

[Michael Catanzaro]

(In reply to Michael Catanzaro from comment #16)
> For now this should only affect Builder and gnome-initial-setup. We'll
> imminently (next few days) release new unstable versions of all of these
> that depend on the 6.0 API. Once that's done, it will be safe to update
> development distros to 2.39.1.

gnome-initial-setup 44.alpha.1 is out now, and Builder 43.3 will be out soon.

I haven't gotten in touch with Milan regarding evolution-data-server yet. He might be on holiday, perhaps. Regardless, this one has a build option -DENABLE_OAUTH2_WEBKITGTK4=OFF which you can use to turn off the GTK 4 web view in the meantime. Or just patch it to use webkitgtk-6.0: it should only be a one-line change.

[Alberto Garcia]

Ideally I think I would like to have webkitgtk-6.0 in bookworm, the timing is going to be complicated, but maybe I can try with the development versions, since the package is anyway going to be updated as soon as the first security updates appear.

If I understood correctly I should not expect API/ABI stability until 2.39.90, right?

[Michael Catanzaro]

(In reply to Alberto Garcia from comment #20) 
> If I understood correctly I should not expect API/ABI stability until
> 2.39.90, right?

Right, that's the plan. But if we fail at that goal, then you could have a problem. This depends on (a) speed at which I post API change patches, (b) speed at which they are reviewed, (c) whether somebody else helps. I think we can do it, but so far I've been going slower than will be required.

Maybe it would be safer to just not have the GTK 4 version in bookworm at all? Maybe ship with Builder 42 and gnome-initial-setup 42 instead of the 43 versions? What does the Debian schedule look like?

[Jeremy Bicha]

(In reply to Michael Catanzaro from comment #21)
> Maybe it would be safer to just not have the GTK 4 version in bookworm at
> all? Maybe ship with Builder 42 and gnome-initial-setup 42 instead of the 43
> versions? What does the Debian schedule look like?

I don't think it's practical to drop the GTK4 library. Debian "Bookworm" already has GNOME 43. GNOME Builder and GNOME Initial Setup are on this side of the big libsoup3 transition.

Same thing for every GNOME 43 distro.

[Michael Catanzaro]

OK, let's race to stabilize things then. Please follow bug #210100 for progress updates. We have about three months to fix the API bugs. The non-API bugs can be dealt with later.