Schema: Features gated to channels

[Elchi3]

The majority of feature gates are flags or preferences nowadays, but some experimental features are gated to a specific release channel such as Nightly or Canary. I'm unclear how to represent this in the current schema. These channels change version numbers every 6-10 weeks and are updated daily.

Collecting examples:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/ArrayBuffer/transfer
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/values

Should we expand the "flag" object to contain type: "channel"?

"firefox": {
  "version_added": false,
  "flag": {
    "type": "channel",
    "name": "Firefox Nightly"
  }
}

[jwhitlock]

This is tough. On one hand, I like to have machine-readable data for things like this. On the other hand, I'm not sure what the compatibility table should do with this information, or a browser plugin, or a caniuse-type display. Available in nightly is interesting for someone who wants to play with a feature, but not for shipping a website. I'm not sure that the machine-readable data is much more useful than a plain note "Available in Nightly as of Aug 30".

[praveenpuglia]

I think the compat data should focus on the following things.

1. When a feature/property/value was really added to the stable version of a browser because most users are on stable channel.

• Prefixed version
• Standard version

2. Data readability by a program and building the data around it. Which @jwhitlock has already mentioned. Example - The VSCode CSS Language Service needs to have this info in order to give proper autocompletion info in the editor.

Since developers might still need to know which features they can try out in nightlies, whatever UI is build to consume this compat data, that can have a "future" section which can list things which browsers are experimenting with. Right now, every browser has it's own channel of broadcasting what's new or what's coming up. But it can all live here and people get one source. Folks from browser vendor sides can come in and update this data whenever they feel like?

[a2sheppy]

Couldn't you just put "Nightly" in the version field?

[SebastianZ]

We already have compile_flag as type, which also goes in the direction of not being available normal release versions.
So, while a browser release channel isn't really a "flag", I think it's totally fine to have that info as machine readable data. If it's added to the data, I think the version, in which it got added should also be exposed.
This allows consumers of the data to display some information in the sense of "Be aware, this feature is only available in Firefox Nightly starting from version 60, it is not available in a stable release yet."

Sebastian

[a2sheppy]

I do feel that having the channel information present is useful. Especially for experimental features that linger on the nightly channel for several releases. You want people to know about them, but also be clear that it's still so deeply experimental it hasn't been riding the trains, so to speak.

I don't see the harm in adding a channel field which can have values taken from among:

• nightly
• alpha
• beta
• release (optional; if channel field is missing, this is the default)

These are generic terms for the pretty standard channels that exist in most products. It would be up to the front-end to map these to the channel-specific names (like nightly → "Canary" for Chrome; and I assume that even though technically it's based on beta now, we'd use alpha → "Developer Edition" for Firefox.

Related, this would also let us note in machine-readable terms the progress of a feature along the train; just add another version record for each time it moves to another channel.

[Elchi3]

More discussions on this
https://discourse.mozilla.org/t/bcd-safari-tech-preview/33790
https://discourse.mozilla.org/t/bcd-question-flag-and-enabled-by-default-in-nightly-only/33449
#3103

Seems like "version_added": "nightly" is the latest proposal on this.
There was also a proposal to add a restriction field.

The next steps here are:

• investigate the different proposals
• audit the data in the repo to see how often we have "Nightly" cases
• find out which proposal would suit us best for the found cases
• research how data consumers would display nightly data (first and foremost MDN, but also VS Code) and why these matter to them.
• research how nightly data will be maintained (nightly is a moving target).

[a2sheppy]

Some thoughts on the next steps listed above (which I think is a good list, btw -- nicely put!):

• While I'm not sure how often we see "nightly" cases specifically, there's certainly the feeling that it's often enough to be worth finding a solution (for me, anyway). Both Chrome and Firefox have features that are added to the experimental or nightly builds (canary or nightly for example) but don't ride their way down to release immediately. It's still worth sharing the availability of many or most of these features, to encourage experimentation and testing, while allowing the consumer of the data to determine how or if to present that information.
• We can't really use version_added for this purpose. "version_added": "nightly" loses the information about what nightly version first added the feature. This is why I propose a separate field for this information.
• It's worth considering if we want to allow the possibility of including special builds, such as if you have to use a special experimental branch of a browser in order to use a feature. Obviously that's extreme edge case country though.
• I could see MDN, for example, presenting the information by displaying the version the same way we do now, but with perhaps a different background color and with text like "(Nightly only)" or a footnote "Available only in Firefox Nightly builds."
• Others, like perhaps certain compatibility testers, might choose not to even use entries marked as being nightly-only.
• It should be simple enough to create a tool to help monitor these. During each release cycle, you could run a tool that would list out all the channel-limited stuff and let you choose to remove or change the restrictions as appropriate.

The more I think about it, the more I like the idea of a channel field as I suggested in a previous comment, but with perhaps the addition of a "special" value, indicating a special build rather than alpha, beta, etc.

[a2sheppy]

Instead of channel, maybe call it release-type. And probably worth allowing release-candidate as a value. I don't know how many of the browser outfits have RC builds anymore but it's worth allowing for the possibility.

[ddbeck]

I'm not trying to revive this issue, but I wanted to make a note while it was on my mind. In #3752, we dropped compile flags. I think however we decide to handle nightly or beta data—that is, variant builds of a browser—needs to square with the idea of omitting compile flag data (maybe this is unsquarable—I have not given it enough thought yet).

[Elchi3]

In #5072 (comment) @sideshowbarker expresses a use case for non-release data:

Part of the context here is that in the W3C/WHATWG world, we are now using the BCD data as part of the work we do in evaluating browser conformance to specs. In particular, we’ve been adding mechanisms to our spec-publishing tools that annotate the specs with links to MDN and with data from BCD. And for our purposes, what we care about is if there’s any version of a particular browser which has implemented support for a particular feature — even if it’s only in the current trunk build and not yet in a stable version widely used by developers.

[Elchi3]

This was fixed by #10334