A long comment here. The first part memorializes some out-of-band discussion that came up on this topic today. The second highlights the specific suggestions for this PR which came out of the discussion.

Recap

• I'm a strong -1 on the alternative Allow ranges for any browser version #19014 and a pragmatic +0 on this proposal. I have a specific consumer motive that is limited by ranged versions: they get in the way of summarizing data across multiple features. Version ranges are sort of contagious. The presence of a ranged version in one feature taints the ability to summarize data of it and related features. That said, ranges already exist and adding a few more is not a major departure from the status quo.

• @Elchi3 noted that the specific ranged versions proposed in this PR could replace many true values while ensuring that recent (i.e., 2020+) data meets a high level of precision.

• @hamishwillee raised the general question of "who cares?" in regards to older versions. Surely ranged versions are better than no versions? He also noted that the current bar means that it's too time consuming to bother with creating data for some features—even though he could easily find a feature's support in recent versions.

• I noted that the specific time horizon to choose may not be arbitrary. For example, recent survey results shared with the WebDX CG suggested that most developers care about some number of major versions of browsers, but some browsers have longer release cadences (specifically Safari on iOS being tied to iOS releases). This might inform where to draw the line. (More on this in the next section.)

• We also discussed the history of ranged versions in BCD and how they came about. I characterized ranged versions as "null lite." Florian highlighted the existing schema docs, which seemed to predict some future temptations:

  Ranged versions should be used sparingly and only when it is impossible to find out the version number a feature initially shipped in.

  He added, "it is a good idea to think about how we want the data to evolve in the long term and that should guide us in how we make data guidelines and rules."

PR suggestions

• For my part, I'd like to suggest that if this line is drawn to the last release of each browser in 2019, rather than the first of 2020. This comes from two places. First, it would align to an iOS major version release (Safari iOS 13 released 2019-09-19), on the estimation that the most conservative constraints that a web developer might face is support a specific major version of iOS. Second, I like the idea, aesthetically, of trusting that all new feature introductions from 1 January 2020 will be precise.

• Florian suggested to "update the docs to mention our idea of the 2020 horizon that divides between precision and allowing ranges." I endorse documenting the motivation, regardless of where the line is ultimately drawn. It'll probably serve us in discussions like this in the future.

A later response from @queengooborg :

I’d like to argue the point that allowing more ranged values would not decrease our accuracy all that much (if at all). In fact, it would only help us increase our accuracy and coverage by helping us replace a bunch of “true” values, right away. I want to be clear: I do NOT want ranged values to remain a thing in three or four years (the same as true/null), they’re only meant to be a temporary solution until the research is put in to determine the exact version number.

I very very strongly agree. From my perspective #19014 makes much more sense - mostly because this PR will not solve the mess that is WebRTC.

Perfect is the enemy of good here.

I think both this and #19014 are improvements to the status quo that lets us make incremental progress on the data quality.

However, I prefer @queengooborg's approach in #19014 of allowing ranges anywhere. I think that consumers in practice would do well do follow MDN and drop the "≤" on display. If most consumers do this, ranges would mostly be for BCD maintainers to call out uncertainty, and I think it would often be the right tradeoff for time spent. Currently, when it's not worth nailing down the exact version, the options are pretending to know or just not updating the data.

Of course I think reviewers should be free to spend extra time to eliminate ranges when doing review, and I just might because I can pin down most changes in source code history.

After a brief chat earlier, @foolip asked me to summarize my position here. My position is that any outcome that results in ranges for pre-2020 versions is fine by me (preferably allowlisted, but arbitrary is also OK). That is to say I'm OK with this PR or #19146. I'd be rather less pleased by #19014.