Bug 245296

Summary: [GTK] Bump GTK 4 API version to -6.0
Product: WebKit Reporter: Michael Catanzaro <mcatanzaro>
Component: WebKitGTKAssignee: Michael Catanzaro <mcatanzaro>
Status: RESOLVED FIXED    
Severity: Normal CC: aperez, berto, bugs-noreply, calvin.walton, cgarcia, jbicha, mcatanzaro
Priority: P2    
Version: WebKit Nightly Build   
Hardware: PC   
OS: Linux   
See Also: https://bugs.webkit.org/show_bug.cgi?id=247098
Bug Depends on:    
Bug Blocks: 210100    

Description Michael Catanzaro 2022-09-16 13:51:02 PDT
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.
Comment 1 Carlos Garcia Campos 2022-09-19 00:54:09 PDT
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.
Comment 2 Michael Catanzaro 2022-09-19 06:57:19 PDT
It's required to build GNOME 43 anyway (needed by gnome-initial-setup and gnome-builder).
Comment 3 Calvin Walton 2022-09-19 07:17:07 PDT
(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.
Comment 4 Michael Catanzaro 2022-09-19 07:50:50 PDT
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.
Comment 5 Adrian Perez 2022-09-19 08:11:38 PDT
(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.
Comment 6 Adrian Perez 2022-09-19 08:12:29 PDT
(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 ;-)
Comment 7 Michael Catanzaro 2022-09-19 09:02:53 PDT
(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.
Comment 8 Michael Catanzaro 2022-09-19 09:04:11 PDT
(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.)
Comment 9 Calvin Walton 2022-09-19 10:13:51 PDT
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.
Comment 10 Michael Catanzaro 2022-09-19 10:28:08 PDT
(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.
Comment 11 Carlos Garcia Campos 2022-09-20 00:51:04 PDT
GTK4 support is still work in progress, and we never meant to release it, I see we added the build option as public though.
Comment 12 Carlos Garcia Campos 2022-09-20 00:53:23 PDT
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.
Comment 13 Michael Catanzaro 2022-09-20 09:25:54 PDT
Pull request: https://github.com/WebKit/WebKit/pull/4531
Comment 14 EWS 2022-10-25 06:16:26 PDT
Committed 255953@main (cd4c7d74bfbd): <https://commits.webkit.org/255953@main>

Reviewed commits have been landed. Closing PR #4531 and removing active labels.
Comment 15 Alberto Garcia 2022-11-11 06:48:23 PST
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?
Comment 16 Michael Catanzaro 2022-11-11 07:27:49 PST
(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.
Comment 17 Alberto Garcia 2022-11-11 07:35:17 PST
(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.
Comment 18 Michael Catanzaro 2022-11-11 08:11:22 PST
(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.
Comment 19 Michael Catanzaro 2022-11-14 13:46:38 PST
(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.
Comment 20 Alberto Garcia 2022-11-15 08:44:07 PST
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?
Comment 21 Michael Catanzaro 2022-11-15 09:18:32 PST
(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?
Comment 22 Jeremy Bicha 2022-11-15 09:39:52 PST
(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.
Comment 23 Michael Catanzaro 2022-11-15 09:43:09 PST
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.