Concrete proposal

Here’s a concrete proposal for marking up data for pre-release browser versions; let’s start doing one of the following:

1. Start using Safari Technology Preview release numbers in addition to Safari major-release numbers; or
2. Start using some generic value “pre-release version” value — for example, dev or pre-release or whatever; or
3. Start using values that correspond to how the browser projects actually label there particular pre-release versions; for example, nightly, canary, and TP (technology preview).

Problem description

The concrete proposal above is intended to address a problem that we’ve had discussion about before. So maybe this is a basically duplicate of an existing issue. If so, I can just take all of the following and add it as comment to that other issue later.

Here’s a detailed explanation of the actual problem I am hoping we can find a way to solve together:

We’re aware that we have a significant number of cases when we know support for a certain feature has been implemented in a particular browser, but only in a pre-release version. And in those cases, if we do not yet have that version number in any https://github.com/mdn/browser-compat-data/tree/master/browsers file, then we have no way of updating the related BCD data to indicate the browser in question has support for that feature.

I assert that’s a deficiency which we should try to find some way to correct — because the data point “this browser has implemented support for this feature” is a useful fact, regardless of what the actual browser version is.

In particular, I think that “this browser has implemented support for this feature” data is potentially useful to downstream consumers of the BCD data.

And more particularly, I can state that it’s absolutely useful to the downstream-consumer tooling that I maintain myself at https://github.com/w3c/mdn-spec-links and that’s used for adding MDN annotations to all W3C and WHATWG specs.

So I’d like to request that we re-consider coming up with some way to mark our data for such cases.

The special problem with Safari data

It’s worth noting here that this is a bigger problem for the Safari data than it is for the Chrome or Firefox data. The reason is that while major numbered versions of Firefox and Chrome are released every six or seven weeks (that is, 7 or 8 releases each year) — major numbered versions of Safari are released only every six months (that is, only twice a year; typically with one major release in March and then another in September).

What that ends up meaning for us is that we have to wait a very long time between Safari releases before we can update our data — even in cases where we know that something has already shipped in a Safari Technology Preview release.

Safari gets actually get updates often; let’s stop ignoring the existing feature data already available

We actually do have numbered versions of Safari shipping quite often; in fact, a new Safari Technology Preview release seems to be shipped on average every four weeks at least — even more often than Firefox or Chrome releases.

So we actually have the data for Safari — that is, we have data for numbered versions of Safari that are being released even more often than numbered versions of Chrome and Firefox.

However, what we’re basically doing is, we’re completely ignoring that data — the data we have for features on those numbered versions of Safari — because we are choosing arbitrarily to limit ourselves to only adding data for features in the two versions of Safari each year that Apple chooses to give major-release version numbers to.

Recognizing that BCD data has use cases beyond just tables in MDN and caniuse.com

In past discussions, the response I’ve received about why we choose to constrain our Safari feature data to only major Safari versions is, we do things that way because those two-releases-a-year Safari versions are the only Safari releases that ship to end users, and so those are the only versions that developers need to care about.

That point of view would make sense if the only imaginable use of the BCD data were for developers wanting to know which shipped-to-end-users versions of browsers have particular features.

But that is of course not the only imaginable use of BCD data. There are lots of other ways we can easily imagine BCD data being used that aren’t limited just to identifying shipped-to-end-users browser versions.

In fact I have an existence proof of such a usage of BCD data: https://github.com/w3c/mdn-spec-links — which is completely agnostic to whether a feature is implemented in a shipped-to-end-users browser version, or not. All that matters for that use of the BCD data is whether the browser has implemented a feature at all, in any version at all.

Let’s stop artificially constraining the possible use cases for BCD data

What we are storing in this repo is data. And we should not be making arbitrary assumptions about how that data is used or by whom. The Browser Compatibility tables in MDN and tables at caniuse.com are just one kind of possible use of the data.

So we rightly should not have policies that artificially constrain the data to only being useful for that one kind of case, and that arbitrarily obstruct the utility of the data for many other possible use cases.