What does "preview" mean for Firefox and Chrome?

[saschanaz]

I think "preview" is meaningful for Safari because their TP releases have no version number, but what does it mean for Firefox and Chrome that give version numbers for nightly/canary builds?

In other words, in what situation would "preview" be preferred over actual version number?

"chrome": {
  "version_added": "preview", // why not an actual version number?
  "flags": [
    {
      "type": "preference",
      "name": "enable-experimental-web-platform-features",
      "value_to_set": "enabled"
    }
  ]
},

[Elchi3]

but what does it mean for Firefox and Chrome that give version numbers for nightly/canary builds?

They give a version number but that version number is a moving target and so preview should be used. If you implement a feature gated to a nightly channel today it will have version 94, for example. Then it doesn't ride the train out of Nightly, so in 4 weeks Nightly is 95. In order to avoid updating BCD every 4 weeks for such features, use preview.

Original issue/discussion: #338

[saschanaz]

So should I think preview as the moving target only for Firefox and Chrome? Because I think preview for Safari is not really a moving target, it's fixed but just has no name.

And does that mean the following is now illegal?

"chrome": {
  "version_added": "90", // version 90 added the initial support behind a flag
  "flags": [
    {
      "type": "preference",
      "name": "enable-experimental-web-platform-features",
      "value_to_set": "enabled"
    }
  ]
},

[Elchi3]

Safari TP has numbers, too, and is a moving target. 120, 121, etc. We don't use these either, we use preview.

And does that mean the following is now illegal?

No that support statement looks good to me. Features can be behind flags in release browsers or in Nightly browsers. In other words: features can be restricted by channel or by preference, or even both, there is no dependency.

[saschanaz]

Safari TP has numbers, too, and is a moving target. 120, 121, etc. We don't use these either, we use preview.

Hmm yeah, but I mean "fixed" that they will be in the next release, with whatever version number.

features can be restricted by channel or by preference

So I wonder whether splitting preview and preview-only makes sense, where the former means the feature will be in the next whatever release, and the latter does not.

[Elchi3]

preview makes no assumption about whether a feature will be in the next release. It is is one of the reasons we didn't went with the Safari TP 121 versions, etc.: it does not give the impression, that it will ship. It is a preview feature, meaning it could either land at some future version or be discarded because the spec changed / people changed their minds.

So, I believe the semantics you see in preview-only is already in preview.

[saschanaz]

preview makes no assumption about whether a feature will be in the next release.

I think it kinda does? Because if a feature is implemented in Firefox Nightly 93 without a flag, then the version number will be 93 instead of preview, and that already makes an assumption.

[ddbeck]

Safari is not really a moving target

they will be in the next release, with whatever version number

According to the folks at Apple, we shouldn't assume that features in Safari TP will graduate to the next versioned Safari release. In other words, we should act as if Safari TP is a moving target with respect to the generally-available Safari, even if Safari TP itself uses fixed versions independently of Safari proper.

In other words, in what situation would "preview" be preferred over actual version number?

I think the answer to this is: any time the stable version number is low-confidence or unknown to BCD. Some examples:

• Some feature is expected in the next release of Safari, but Apple hasn't announced a version number (so our data doesn't have a version number). Use "preview" until the number is announced.
• Some feature is in a Chrome Canary, but it's still early in development, so it's undecided whether it will make the cut to advance to beta and stable (e.g., a feature in today's Canary 95 isn't clearly going to advance to the eventual Chrome 95 release). Use "preview" until there's public statements of confidence for release, or it advances to a fixed beta/stable version number.

[Elchi3]

I think it kinda does? Because if a feature is implemented in Firefox Nightly 93 without a flag, then the version number will be 93 instead of preview, and that already makes an assumption.

So, a feature gets implemented in the 93 cycle without a flag. Two possible scenarios from here:

• It can they normally ride the train to release: BCD records 93 (and if 93 is not yet released, BCD makes assumptions).
• It can be gated nightly only and doesn't ride the train to release. BCD records preview and makes no promises about when it will be in release.

[saschanaz]

and if 93 is not yet released

(I think this can't happen for Firefox/Chrome, or can it?)

• It can be gated nightly only and doesn't ride the train to release. BCD records preview and makes no promises about when it will be in release.

So there is an assumption, right? Although it makes no promises when (for which I personally don't have an interest).

[Elchi3]

Not riding the train and staying in Nightly as a moving target is the assumption, yes.

[ddbeck]

Oh, perhaps an additional frame for this: use "preview" to protect the quality of stable data in the face of schedule uncertainty.

If you enter a number for a not-yet-stable release but you're not actually certain that number will continue to be correct when that number is the stable release, then use "preview" instead. Or if a feature is explicitly barred from reaching beta or stable (I recall nightly and canary-only build flags, though I don't know if that's conventional in either project presently) and you don't know what number to which it will eventually be assigned, then use "preview".

In those cases, BCD isn't saying they'll eventually be released to a stable version, just that they are available in the preview builds.

[saschanaz]

Thanks, that's clearer to me. To summarize my understanding:

• "preview" is used when one cannot make sure a feature will ride the train to the stable versions
• Apple explicitly requested not to assume anything about it, so a feature only in TP will be always "preview"

BCD isn't saying they'll eventually be released to a stable version

I think using version number says they will, because if not it will be "preview", if I understand this conversation right 👀

[ddbeck]

That reads right to me. 👍

Actually, your summary sounds like the start of a documented data guideline. I'd like to hold this issue open until I've had a chance to do that.