Bug 228250 - [GTK] Use webkit2gtk-4.5 for GTK 4 API version
Summary: [GTK] Use webkit2gtk-4.5 for GTK 4 API version
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: WebKit Nightly Build
Hardware: PC Linux
: P2 Normal
Assignee: Michael Catanzaro
URL:
Keywords:
Depends on:
Blocks: GTK4
  Show dependency treegraph
 
Reported: 2021-07-23 14:48 PDT by Michael Catanzaro
Modified: 2021-11-17 06:52 PST (History)
10 users (show)

See Also:


Attachments
Patch (3.62 KB, patch)
2021-07-23 14:51 PDT, Michael Catanzaro
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Catanzaro 2021-07-23 14:48:02 PDT
I think it would be nice to try to align our API version with the GTK version, to reduce confusion in the future. It's not possible currently because our GTK 3 APIs are webkit2gtk-4.0 and webkit2gtk-4.1, but it *will* be possible in a future GTK 5 API *if* we don't bump our API version to webkit2gtk-5.0 now. Instead, I'd propose calling the GTK 4 API webkit2gtk-4.5, halfway between 4.0 and 5.0. Then we can call the future GTK 5 API webkit2gtk-5.0.

We may also want to drop the legacy 2 from the API version, i.e. webkit2gtk-4.5 -> webkitgtk-4.5, to simplify things more. Or we could decide to keep it forever.
Comment 1 Michael Catanzaro 2021-07-23 14:51:06 PDT
Created attachment 434126 [details]
Patch
Comment 2 Michael Catanzaro 2021-07-23 14:57:36 PDT
Alternatively, we could try to copy distro packaging by adding the GTK version to the middle of the API version. E.g. instead of webkit2gtk-4.0, we could have webkit2gtk4-5.0 (but it feels like too much versioning?). Or we could omit the versioning entirely and just have webkit2gtk5 (but having the version seems nicer to me).

What I'm trying to avoid is having to know this arbitrary mapping of WebKitGTK API versions to GTK versions:

webkit-1.0 - WebKitGTK for GTK 2
webkitgtk-3.0 - WebKitGTK for GTK 3, LegacyWebKit
webkit2gtk-3.0 - WebKitGTK for GTK 3, modern WebKit, version 2.4 and earlier
webkit2gtk-4.0 - WebKitGTK for GTK 3, with libsoup 2, version 2.6 and later
webkit2gtk-4.1 - WebKitGTK for GTK 3, with libsoup 3

It's not so hard if you're a WebKit developer and have the table in front of you, but for developers using WebKit it's actually quite confusing.
Comment 3 Carlos Garcia Campos 2021-08-03 07:57:04 PDT
I find weird to use 4.5 for a new major API version, 4.1 was used because the API is the same, only binary compatibility was broken, so it's a new version of the 4 series. But a new version breaking the API and removing interfaces should have a new number in my opinion. I'm fine with removing the 2 from the library name, though. We are no breaking the API because of GTK4, but we might need to break the api in the feature before GTK5 is released and we would be out of sync with GTK again.
Comment 4 Michael Catanzaro 2021-08-03 15:07:35 PDT
(In reply to Carlos Garcia Campos from comment #3)
> I find weird to use 4.5 for a new major API version, 4.1 was used because
> the API is the same, only binary compatibility was broken, so it's a new
> version of the 4 series. But a new version breaking the API and removing
> interfaces should have a new number in my opinion. I'm fine with removing
> the 2 from the library name, though. We are no breaking the API because of
> GTK4, but we might need to break the api in the feature before GTK5 is
> released and we would be out of sync with GTK again.

Well it's up to you. I don't see a problem with 4.5. If we need an unexpected API bump, we could have webkitgtk-4.6, webkitgtk-4.7, webkitgtk-4.8 etc. so there's plenty of room to avoid desyncing with GTK.

But if you prefer 5.0, fine. I can still look into how hard it would be to drop the 2.
Comment 5 Carlos Garcia Campos 2021-08-04 00:05:17 PDT
(In reply to Michael Catanzaro from comment #4)
> (In reply to Carlos Garcia Campos from comment #3)
> > I find weird to use 4.5 for a new major API version, 4.1 was used because
> > the API is the same, only binary compatibility was broken, so it's a new
> > version of the 4 series. But a new version breaking the API and removing
> > interfaces should have a new number in my opinion. I'm fine with removing
> > the 2 from the library name, though. We are no breaking the API because of
> > GTK4, but we might need to break the api in the feature before GTK5 is
> > released and we would be out of sync with GTK again.
> 
> Well it's up to you. I don't see a problem with 4.5. If we need an
> unexpected API bump, we could have webkitgtk-4.6, webkitgtk-4.7,
> webkitgtk-4.8 etc. so there's plenty of room to avoid desyncing with GTK.
> 
> But if you prefer 5.0, fine. I can still look into how hard it would be to
> drop the 2.

I'm not sure, TBH. We still have time to decide. We can start by removing the 2 for now.
Comment 6 Michael Catanzaro 2021-08-04 08:30:24 PDT
(In reply to Carlos Garcia Campos from comment #5)
> We can start by removing the 2 for now.

Turns out this is hard. :D

pkg-config is easy enough, but there is also:

 * .so library name
 * public include path
 * gtk-doc package
 * bazillions of internal paths, e.g. derived sources and framework headers

We might need to go one at a time....
Comment 7 Michael Catanzaro 2021-11-04 11:57:10 PDT
tbh removing the 2 might not be worth the effort.

Changing just the API version is a lot easier, since that only needs to be changed in just a couple places.