Intended meaning/precision of WebKit engine version?

[foolip]

Since Safari 9, WebKit engine version numbers in safari.json and safari_ios.json are given with 3 version components. For example, Safari 14 is 610.1.28: https://github.com/mdn/browser-compat-data/blob/e05c9e9ad76ff6023d5c717059d682e8b4e778f8/browsers/safari.json#L170-L176

However, current Safari 14.0.2 has "16610.3.7.1.9" in "About Safari", which I take to be WebKit 610.3.7.

Neither 610.1.28 or 610.3.7 are WebKit trunk versions, those reached only 610.1.26 and 610.2.2 before bumping to 611.

Since I've used these numbers to figure out the Safari version for a change from WebKit trunk, knowing how to interpret it is important.

So, should this be the WebKit version given in the earliest release of that Safari version, or should it be the version of WebKit trunk it was based on?

[foolip]

cc @gsnedders

[foolip]

One thing I'm not sure about is versions from Safari release branches. The Safari 13.0 branch has version 608.1.49, while 13.0.1 is 608.2.11, matching BCD. I'd assume BCD was wrong here, but 13.0.1 is the earliest run we have in wpt.fyi, and I'm not sure how we'd be certain if 13.0 was the first stable release.

[ddbeck]

I think a lot of the Safari and WebKit engine version numbers are best guesses. Look at a PR like #3877, for example. Before Safari froze the UA string, we had a plausible way of tracking the underlying engine by taking what Safari itself was reporting about the engine version. Now we don't have that I'm not sure what to do about it.

There's another layer to this problem too, which is that we have this whole "release lines" thing, which is to treat 13.0.0 (assuming it exists) and 13.0.1 as if they were the same (under the assumption—perhaps faulty!—that users are very likely to get patch updates quickly, but not major versions).

I'd be happy to regularize the version numbers somehow (e.g., to only use the WebKit branch point exclusively), but I'm not sure what method makes sense or how practical it would be to go back and re-confirm the historic versions.

[gsnedders]

cc @jensimmons @apple-web-evangelist

Since Safari 9, WebKit engine version numbers in safari.json and safari_ios.json are given with 3 version components. For example, Safari 14 is 610.1.28:

https://github.com/mdn/browser-compat-data/blob/e05c9e9ad76ff6023d5c717059d682e8b4e778f8/browsers/safari.json#L170-L176

However, current Safari 14.0.2 has "16610.3.7.1.9" in "About Safari", which I take to be WebKit 610.3.7.

The bundle versions are prefixed with a string based on OS version for macOS, hence the "16" prefix.

Safari and WebKit are (at least currently) versioned together, so it's 610.3.7.1.9 (i.e., https://trac.webkit.org/browser/webkit/tags/Safari-610.3.7.1.9). Note that 610.3.7.1.9 is a different tag to 610.3.7, as it has branched off from that. (The five-tuple versioning seems to date from https://github.com/WebKit/WebKit/commit/6dd09485da4d748528a3defb98be8783a9a6de2f in 2014.)

Neither 610.1.28 or 610.3.7 are WebKit trunk versions, those reached only 610.1.26 and 610.2.2 before bumping to 611.

I'll let others post more about the detail of the numbering scheme, if they want. In general though, I'd suggest not reading too much into them.

Since I've used these numbers to figure out the Safari version for a change from WebKit trunk, knowing how to interpret it is important.

Note that many changes are cherry-picked into the release branches, so it's not implausible the two won't follow. This is especially true for anything behind a setting or compilation flag, as the defaults can change on the branches.

So, should this be the WebKit version given in the earliest release of that Safari version, or should it be the version of WebKit trunk it was based on?

I'd definitely go for the version of the initial release. Though at least in the Big Sur case that's slightly complicated (11.0, which only shipped as a factory-install on early M1-based hardware, had 610.2.11.1.3; 11.0.1, which actually shipped first, had 610.2.11.51.8).

Where it branched off from trunk is really a development detail, and not really relevant to web developers. Once we've moved to git it'll become much easier to check if a given commit is within a given tag.

One thing I'm not sure about is versions from Safari release branches. The Safari 13.0 branch has version 608.1.49, while 13.0.1 is 608.2.11, matching BCD. I'd assume BCD was wrong here, but 13.0.1 is the earliest run we have in wpt.fyi, and I'm not sure how we'd be certain if 13.0 was the first stable release.

The "releases" tags are done on an adhoc manual basis; it's totally plausible someone just tagged the wrong thing.

That said, iOS 13.0 shipped with 608.1.48 which is off-by-one; iOS 13.1 shipped with 608.2.11.0.1, and macOS 10.15 shipped with 608.2.30.1.1. (I have not looked at the other macOS versions that Safari 13 shipped on; they may differ further.)

I think a lot of the Safari and WebKit engine version numbers are best guesses. Look at a PR like #3877, for example. Before Safari froze the UA string, we had a plausible way of tracking the underlying engine by taking what Safari itself was reporting about the engine version. Now we don't have that I'm not sure what to do about it.

For the macOS releases the Safari version and the WebKit ( & WebKitLegacy, etc.) framework versions are both easily inspectable (/Applications/Safari.app/Contents/version.plist and /System/Library/Frameworks/WebKit.framework/Resources/version.plist, though they should always match). For iOS I think the SDK/Simulator might have it somewhere?

[foolip]

Thanks @gsnedders, that's super helpful!

Since I've used these numbers to figure out the Safari version for a change from WebKit trunk, knowing how to interpret it is important.

Note that many changes are cherry-picked into the release branches, so it's not implausible the two won't follow. This is especially true for anything behind a setting or compilation flag, as the defaults can change on the branches.

Yeah, this is true for all engines. Still, for changes far in the distant past, where one can inspect the change and be pretty confident it's not behind a flag and not very likely to be reverted or backported, I've used this method to get some version without having to write a test. There's a chance some of these end up off-by-one, but it doesn't matter that much if it's 10 years in the past already.

So, should this be the WebKit version given in the earliest release of that Safari version, or should it be the version of WebKit trunk it was based on?

I'd definitely go for the version of the initial release. Though at least in the Big Sur case that's slightly complicated (11.0, which only shipped as a factory-install on early M1-based hardware, had 610.2.11.1.3; 11.0.1, which actually shipped first, had 610.2.11.51.8).

Thanks for confirming! It sounds like we have more precision in BCD than is warranted, and that the WebKit version in the initial release won't necessarily match between iOS and macOS, in addition to possibly differing by hardware.

Where it branched off from trunk is really a development detail, and not really relevant to web developers. Once we've moved to git it'll become much easier to check if a given commit is within a given tag.

Looking forward to that! I hope the branches and tags, including the stuff under old/, are preserved :)

The "releases" tags are done on an adhoc manual basis; it's totally plausible someone just tagged the wrong thing.

That's good to know, thanks!

So all in all, it seems like at least the versions for Safari 13 are wrong, and it's likely that other WebKit versions in BCD are at least slightly wrong, but that to confirm one would need the earliest releases of each OS.

@gsnedders I think sorting this out perhaps isn't very important now that you've explained what to expect. Because of how the branching works I don't think these small errors will ever lead to a different conclusion when trying to guess Safari release from trunk version. But if there's a rainy day and you wouldn't mind checking the WebKit versions >=600 in safari.json and safari_ios, that would be nice.

If we need to reduce the precision to just major+minor in order to not have different versions for paired macOS + iOS releases, I think that would be sensible too.