Bug 228250

Created attachment 434126 [details] Patch

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.

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.

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

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

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

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.

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

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

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

Committed 254269@main (5b5c7d2947db): <https://commits.webkit.org/254269@main> Reviewed commits have been landed. Closing PR #3834 and removing active labels.