version_added is sometimes but not always a range

[ghost]

Sometimes version_added is not a version like 1.1.2.56 but is a string that starts with <= like "<=1.1.1.1".

https://www.github.com/mdn/browser-compat-data/tree/4c50bfdf43261a67d00b830fb0cd3a316a286400/api%2FHTMLMarqueeElement.json

[queengooborg]

For certain browsers, it is near impossible to test older versions. As such, we create ranges for the versions to say "it's at least in this version, but it could be implemented in an older version" (ex. ≤37 means "version 37 or before"). This decision was made in #4330, and has expanded for other browsers in #4610, #6807, and #7337.

[ghost]

I understand why but this can create issues on both the JSON schema and the React if we were to process the data.

So I think it is useful to stay consistent with the type and name "version_added" of type "Version" and at most find another place to communicate this information.

If we really wanted to be strict the answer is null because the data is not known.

You could add a key if you want with an estimate but I am focused on this in object.
Let's assume we had to break it down by character .other characters can create issues.

[queengooborg]

We do outline ranged versions (a version with a ≤ prefix) in our schema documentation -- see https://github.com/mdn/browser-compat-data/blob/master/schemas/compat-data-schema.md#ranged-versions.

Do you have a particular example of the ranged version causing issues? If so, perhaps I can suggest a solution to resolve the issue. Ranged values are pretty baked into the data since pre-1.0.0 BCD, and it's not something that we'd be able to remove or move around within the schema easily. (We do hope to, eventually, remove all ranged values and replace them with specific version numbers, but that's a goal to perform overtime.)

[ghost]

• In this table we say version in the table header.

• The range is clear here but not for the "final reader".

• The data is a version number and not a range of versions.

• When the row should be green and when red?

• Versioning in BCT yari#1925

• table.bc code.version yari#1941

• ≤ is ambiguous on MDN yari#1607

[queengooborg]

Thanks for the example, and I see your point. From your first linked issue (mdn/yari#1925), I found mdn/yari#1607 which talks more about the display on the MDN web docs pages. May we get your input on that issue? (I'm seeing this as more of a display issue on the MDN pages rather than a data issue, but I'll ask @ddbeck what he thinks when he is back.)

[ghost]

mdn/yari#1607 Is the more discussed. Is everiting "connected".

The point is that datas are 2 types:

• added: a version number or null or undefined (the key).
• supported: a boolean (We Need for the colors, should be computed in JavaScript?)

The range could be important for example if We want to say always N versions so

• implemented in a browser
• unsupported in a browser
• current version of the browser
• supported (boolean computed from the 3 version above, depends on the current version of the browser)

The problem Is that the this sometimes Is a browser (User agent) and sometimes Is a feature.

[ghost]

The best thing in my opinion at the state of the art would be to null all the versions that are not known ... Since the JSON cannot compute.

Then eventually extend the object/objects.