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.
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.
It's required to build GNOME 43 anyway (needed by gnome-initial-setup and gnome-builder).
(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.
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.
(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.
(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 ;-)
(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.
(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.)
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.
(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.
GTK4 support is still work in progress, and we never meant to release it, I see we added the build option as public though.
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.
Pull request: https://github.com/WebKit/WebKit/pull/4531
Committed 255953@main (cd4c7d74bfbd): <https://commits.webkit.org/255953@main> Reviewed commits have been landed. Closing PR #4531 and removing active labels.
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?
(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.
(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.
(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.
(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.
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?
(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?
(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.
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.