Bug 228250 – [GTK4] Change API version from webkit2gtk-5.0 to webkitgtk-5.0

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

[Michael Catanzaro]

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.

[Michael Catanzaro]

Created attachment 434126 [details]
Patch

[Michael Catanzaro]

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.

[Carlos Garcia Campos]

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.

[Michael Catanzaro]

(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.

[Carlos Garcia Campos]

(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.

[Michael Catanzaro]

(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....

[Michael Catanzaro]

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.

[Michael Catanzaro]

(In reply to Michael Catanzaro from comment #0)
> I think it would be nice to try to align our API version with the GTK
> version, to reduce confusion in the future.

Nobody cares. Probably not worth it.

> 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.

I'm going to investigate the feasibility of doing this. If it's not easy, then I'll close this bug.

[Michael Catanzaro]

(In reply to Michael Catanzaro from comment #8)
> I'm going to investigate the feasibility of doing this. If it's not easy,
> then I'll close this bug.

I thought this was going to work, but problem is #includes in public headers, e.g.:

#if !defined(__WEBKIT2_H_INSIDE__) && !defined(WEBKIT2_COMPILATION)
#error "Only <webkit2/webkit2.h> can be included directly."
#endif

It may be possible if we adopt Adrian's suggestion to use https://dotat.at/prog/unifdef/. I'll investigate that now.

[Michael Catanzaro]

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

[EWS]

Committed 254269@main (5b5c7d2947db): <https://commits.webkit.org/254269@main>

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