Bug 20282 – WebKitAvailability.h has Mac-specific versioning

• Status: RESOLVED
• Resolution: WONTFIX
• Component: JavaScriptCore

[Alp Toker]

The WebKitAvailability.h JavaScriptCore public API header file added WebKit/Mac versioning to JavaScriptCore in r33053:

https://trac.webkit.org/changeset/33053?format=diff&new=33053

This specifies the following versions:

#define WEBKIT_VERSION_1_0    0x0100
#define WEBKIT_VERSION_1_1    0x0110
#define WEBKIT_VERSION_1_2    0x0120
#define WEBKIT_VERSION_1_3    0x0130
#define WEBKIT_VERSION_2_0    0x0200
#define WEBKIT_VERSION_3_0    0x0300
#define WEBKIT_VERSION_3_1    0x0310
#define WEBKIT_VERSION_LATEST 0x9999

Non-Apple ports of WebKit like the GTK+ port don't follow the same API versioning scheme, so WebKit for GTK+ is currently on version 1.0.1 (stable) and 1.0.2 (development) for example.

Encoding WebKit/Mac versioning in the portable JavaScriptCore API adds unacceptable confusion, especially since the WebKit version numbers between ports look very similar, so this is bound to cause confusion.

Additionally, there was no period of public review for this patch, which is a little disappointing. We should have caught this issue before it ever landed.

+        <rdar://problem/4859666> WebKit needs availability macros in order to deprecate APIs

There is already an appropriate bug report for this:

https://bugs.webkit.org/show_bug.cgi?id=20232

I suggest that we back this changeset out immediately before it starts getting used by applications or ends up in a release.

Once this is done we can devise a separate API versioning scheme for JavaScriptCore or find some other way of tying it in with toplevel WebKit API versioning.

[Mark Rowe (bdash)]

I'm open to suggestions, but rolling out the change without any concrete plan on how to improve the situation does not seem reasonable to me.

[Darin Adler]

We can revise this to work well across multiple platforms -- but I don't see the need to roll it out! It seems wrong to have this marked as a P1, since it's not causing any immediate problems for anyone.

[Darin Adler]

Maybe we should just put a Mac OS X or Apple prefix on these macros for now?

[Alp Toker]

(In reply to comment #2)
> We can revise this to work well across multiple platforms -- but I don't see
> the need to roll it out! It seems wrong to have this marked as a P1, since it's
> not causing any immediate problems for anyone.
> 

The immediate problem is that we don't want to freeze WebKit 1.0.2 for GTK+ with public API headers containing macros and documentation for WebKit 3.1 for Mac, so it is something of a blocker for the GTK+ port if nobody else.

I can kick off discussion by suggesting a modification that would be consistent with the JS_EXPORT macros and other header names. We can rename WebKitAvailability.h to JSAvailability.h and change the macros like this:

- JS_EXPORT JSContextGroupRef JSContextGetGroup(JSContextRef ctx) AVAILABLE_AFTER_WEBKIT_VERSION_3_1;
+ JS_EXPORT JSContextGroupRef JSContextGetGroup(JSContextRef ctx) AVAILABLE_AFTER_JS_VERSION_3_1;

The problem here is that the x.y versioning scheme still doesn't offer enough granularity for us since the WebKit/Mac release schedule isn't public, so the macros won't be reliable for our developers.

I'm sure we can find a technical solution that works for everyone (like say, a separate versioning scheme for the JavaScriptCore API that gets bumped by port maintainers). Until that time, I don't believe these changes should be in SVN.

[Mark Rowe (bdash)]

(In reply to comment #4)
> (In reply to comment #2)
> > We can revise this to work well across multiple platforms -- but I don't see
> > the need to roll it out! It seems wrong to have this marked as a P1, since it's
> > not causing any immediate problems for anyone.
> > 
> 
> The immediate problem is that we don't want to freeze WebKit 1.0.2 for GTK+
> with public API headers containing macros and documentation for WebKit 3.1 for
> Mac, so it is something of a blocker for the GTK+ port if nobody else.
> 
> I can kick off discussion by suggesting a modification that would be consistent
> with the JS_EXPORT macros and other header names. We can rename
> WebKitAvailability.h to JSAvailability.h and change the macros like this:
> 
> - JS_EXPORT JSContextGroupRef JSContextGetGroup(JSContextRef ctx)
> AVAILABLE_AFTER_WEBKIT_VERSION_3_1;
> + JS_EXPORT JSContextGroupRef JSContextGetGroup(JSContextRef ctx)
> AVAILABLE_AFTER_JS_VERSION_3_1;

This scheme wouldn't make sense for the uses of these macros in the WebKit API layer.

[Martin Robinson]

This hasn't proved to be an issue for WebKitGTK+, so I think it's safe to close this bug and reopen it if we ever run into problems.