Allow ranged dates and versions for non-threshold support information

[ddbeck]

This issue is blocked on adopting an earliest-possible-date indicator, as in #623.

@foolip, @Rumyra, and I had a chat earlier that veered into this topic. I am trying to capture that conversation, but I invite them to correct me on any misstatements here.

Proposal

Allow an "at least this early" range indicator (e.g., ≤) on status block version numbers and dates, if those dates and versions are Baseline high.

For dates, (i.e., baseline_low_date and baseline_high_date) a range indicator would be taken to mean "this date but potentially earlier." That is, new or wider availability may have been more historical, but not newer.

For version numbers, a range indicator would be taken to mean "supported this version and later." That is, support in preceding versions would be unknown, not unsupported.

Example

Ranges for version numbers would allow web-features to communicate the distinction between caniuse's red, green, and gray boxes. Take this, for example:

The corresponding data would look like this:

support:
  chrome: "45"
  edge: "≤15"
  safari: "7.1"
  firefox: "25"

Presently, our schema would only be able to show unsupported for Edge versions less than 15.

Motivation

This has a few key benefits:

• Shortens the time and effort to set statuses for older features, even when we're certain they're Baseline high
• Provides a transparent way to handle version ranges from BCD (right now we don't show when we source version ranges from BCD)
• Makes it easy to find and prioritize features for later refinement

Though it comes at increased integration burden to consumers (though it's likely most could strip out the indicator).

@foolip and I are spending quite a lot of time picking apart features and cleaning up data in BCD, so that each version numbers reported by web-features is accurate. So far, we've been pretty meticulous, so that a consumer could take version numbers for a feature's support block and report that the feature was supported from those versions continuously to the present and that preceding versions were unsupporting. That's ideal, especially for recent features where it's important for developers to have accuracy through the whole life of the feature.

For older features, however, there's less value in knowing precisely which version marked the beginning of support for a feature while the cost of finding that precise version increases substantially. Whether a feature originally shipped in one of the core browsers in 2017 or 2016 is probably not a make-or-break event for using that feature, as long as we're reasonably certain it's no later than a given date or version number.

[foolip]

I'm very keen on this approach to handling older features. A few things I'd like to see here:

• ≤ in BCD automatically carrying over to computed statuses
• ≤ carrying over to the Baseline low date if the keystone release had ≤

For simplicity, I think we should start with a simple cutoff point for where ≤ is allowed. I would propose that it's OK for any release before 2016, so that there's no uncertainty about the Baseline 2016 (or later) feature set. That would mean:

• Chrome ≤47
• Edge ≤13 (convenient because even getting a VM of Edge 12 is very hard)
• Firefox ≤43
• Safari ≤9

If we find that this is too far back in time and that reviewing is still too slow, we could move the cutoff point to 2020, at least temporarily.

[foolip]

While preparing #1206 I tried a few different things, and there are tradeoffs that I'm undecided about.

• Granular control over where ranges are used vs. a single cutoff point? I like the simplicity of just having a year as a cutoff point, but it will also result in ranges being used where we actually are sure about the correct versions.
• Should we use ranges in dates? Support ranges before a given year with status_uncertain_before #1206 does, but it results in "≤2015-07-29" as a date even though the uncertainty isn't about Edge 12 (released on 2015-07-29) but about the correct versions for Chrome, Firefox and Safari.

I am now leaning towards a more restricted use of ranges than I have prototyped:

• The keystone release can never use ranges, so the Baseline dates can never have ranges.
• If ranges are used, they're used for every release before the Baseline low date. If we're only unsure about one browser, we'll need to track that in comments.
• To start out, only allow ranges when the Baseline low date is 2015-07-29.

This ends up not addressing #623 at all, which I think is good, because that's a different issue, not caused by uncertainty about Chrome/Firefox/Safari, but really about whether a feature was supported in IE.

[foolip]

I've sent #1208 implementing that.