Allow preview browsers in the data structure

[Elchi3]

This PR is based on a discussion that is going on for quite some time now. BCD has no way to represent "Preview browsers". Instead two main workaround have been used:

1. Oftentimes, there are support statements that say "false" but then a note is added to say "Implemented in Nightly/Canaray/TP".
2. Sometimes, a release number far into the future is added (for example "Safari 15") because it is assumed from the support in the Safari Technical Preview browser that the feature will be in that version (although the version number is still somewhat unknown).

Both approaches aren't ideal.

---

This PR experiments with allowing "preview" as an allowed version string for version_added and version_removed.
Further, the browser objects are extended with an optional property preview_name that contains the brand name for these preview browsers ("Canary", "Nightly", "TP") - these names are meant to be short, so that e.g. the MDN compat table renderer can pick them up and displays them in the table cells.

If a browser has a preview_name declared in its browsers/* file, the following statements are allowed:

"safari": {
  "version_added": "preview"
}

"safari": {
  "version_added: "11.1"
  "version_removed": "preview"
}

Disallowed is this:

"safari": {
  "version_added: "preview"
  "version_removed": "11.1"
}

In trees, a parent feature is not allowed to be "preview" when sub features are a version number.

Parent:

"safari": {
  "version_added": "preview"
}

Child:

"safari": {
  "version_added: "11.1"
}

---

Opening this as a draft for now to collect feedback. If this seems plausible, it probably means a major version release for BCD.

[Elchi3]

@apple-web-evangelist @jensimmons @sideshowbarker @foolip here's a PR that follows up on our conversation in our last BCD call regarding preview browsers (Technical Preview, Nightly, Canary). I would be interested in hearing your thoughts on this proposal.

@Fyrd This PR changes BCD to take into account preview browsers. So, for example on https://caniuse.com/mdn-api_abortsignal_abort Safari TP is currently grey/unsupported, but if BCD had "version_added": "preview", you could display the TP cell green/supported. Does this PR make sense for your import tooling?

[jensimmons]

Thanks for pushing this forward.

Above, you wrote

"safari": {
  "version_added: "11.1"
  "version_removed": "preview"
}

Are you thinking that when support ships in an official public release that the "preview" designation should always be removed?

[Fyrd]

@Elchi3 Yes, this PR makes sense and would work for caniuse. Thanks!

[Elchi3]

Above, you wrote

"safari": {
  "version_added: "11.1"
  "version_removed": "preview"
}

Are you thinking that when support ships in an official public release that the "preview" designation should always be removed?

No, I made this example to illustrate where we want to allow "preview" and where not. In this example, a feature is unshipped in a preview browser. For example, an API like AppCache can be removed in TP already, so the version_removed property needs to allow "preview" as a version. Then, someday, if Appcache is also removed in release, "version_removed": "preview" can be updated to "version_removed": "15".

Contrary to that example, the following should not be allowed, because a feature added in preview and having it removed in a stable version makes no sense in my understanding.

"safari": {
  "version_added: "preview"
  "version_removed": "11.1"
}

This is similar to us also disallowing earlier versions for "version_removed". The following makes no sense either:

"safari": {
  "version_added: "15"
  "version_removed": "11.1"
}

[jensimmons]

Are you thinking that when support ships in an official public release that the "preview" designation should always be removed?

No, I made this example to illustrate where we want to allow "preview" and where not.

Cool, cool. Just checking. Because, of course, the most common pattern will be that something lands in a preview browser. Then later it's also added to the release version. And stays in both forever....

I'm glad this is getting figured out!

[foolip]

I love it!

Is the intention that we should now stop recording pre-stable releases as numbers, thus combining beta+dev+canary into a single "preview" release? I think that would be great, but it increases the scope of the changes needed. Perhaps they can be phased out by no longer adding new numbered pre-stable represses?

[Elchi3]

Is the intention that we should now stop recording pre-stable releases as numbers, thus combining beta+dev+canary into a single "preview" release? I think that would be great, but it increases the scope of the changes needed. Perhaps they can be phased out by no longer adding new numbered pre-stable represses?

As discussed in the call yesterday, the additional policies you describe here can be decided on (and linted for) at a later stage, if needed.

[Elchi3]

I'm testing stuff on the rendering side. Please send me "weird" data. So far I have this:

1. Simple "version_added": "preview" scenarios (first row in the screenshot, blue cells)

"chrome": {
   "version_added": "preview"
},
"firefox": {
  "version_added": "preview"
},
"safari": {
  "version_added": "preview"
}

2. Something is removed in a preview browser (like AppCache which unships in preview browsers first). See second row red cell with "8 - TP".

"safari": {
  "version_added": "8",
  "version_removed": "preview"
},

3. The third row attempts to create an expand view scenario. Here something was supported earlier under an alternate name and now a preview browser ships the real thing.

"chrome": [
 {
   "version_added": "preview"
 },
 {
   "alternative_name": "foo",
   "version_added": "39",
   "version_removed": "45"
 }
],

If you have more scenarios, I would love to test them so I can make the rendering as solid as possible. Just comment with some BCD JSON here, thanks :)

Edit: Found a realistic third example.

[foolip]

A fairly plausible scenario is where a prefixed API remains but the unprefixed API is in preview. That was the case for the Fullscreen API at some point. Something like:

"chrome": [
 {
   "version_added": "preview"
 },
 {
   "prefix": "webkit",
   "version_added": "15"
 }
],

[Elchi3]

Would render like this:

[foolip]

For experimental removal in the drawArraysInstancedANGLE example I think this runs into mdn/yari#3971 in a not-great way, showing the range 8–TP. Understanding experimental removals isn't trivial so I hope we don't get a tonne of these, but I do think showing 8–14.1 might be better?

I'm also not sure about the color for these. You can in fact still use such features, and there's no guarantee that the removal will work out. But I don't have a suggestion, I think red is better than any other existing color here.

[foolip]

@Elchi3 I guess the BCD order is taken as-is? How would this render?

"chrome": [
 {
   "prefix": "webkit",
   "version_added": "15"
 },
 {
   "version_added": "preview"
 }
],

Preview features are like flags in many ways, and I think in BCD review I'd ask for this order to show that you can in fact use this feature already, just with a prefix.

[Elchi3]

I do think showing 8–14.1 might be better?

Yeah, I think this is the known version_removed problem which is off by one. There is an issue somewhere. I agree this doesn't happen very often so I think we can fix this later (e.g. Edge 12-79 should be 12-18 etc).

I'm also not sure about the color for these. You can in fact still use such features, and there's no guarantee that the removal will work out. But I don't have a suggestion, I think red is better than any other existing color here.

I guess the only alternative would be blue to show something is up in a preview browser but I wonder if that's more confusing than helpful.

I guess the BCD order is taken as-is?

Yes, it is. And I think BCD should order in a sensible way so that all consumers would benefit from a good order. This is filed in #1596

How would this render?

Looking at this I think the label text "Preview browser support only" should rather just be "Preview browser support" because it doesn't really know if it's the "only" support.

[Elchi3]

I've sent mdn/yari#3997 to Yari, so that MDN would be able to render this.

[gsnedders]

Is the intention that we should now stop recording pre-stable releases as numbers, thus combining beta+dev+canary into a single "preview" release? I think that would be great, but it increases the scope of the changes needed. Perhaps they can be phased out by no longer adding new numbered pre-stable represses?

As discussed in the call yesterday, the additional policies you describe here can be decided on (and linted for) at a later stage, if needed.

It might be worth treating beta slightly differently to anything further from release; it's relatively unusual for there to be so much difference to the final release.

Developers often expect MDN to be up-to-date pretty much as soon as a browser is released, which implies that the data needs to be in MDN prior to release.

[ddbeck]

I'm happy with this. I think we've given this enough thought and it's time to exercise it!