Browser-compat-data: Samsung Internet versions have a trailing `.0`, which is inconsistent with other browser data

[ExE-Boss]

Edit: Turns out this also applies to qq_android.

https://github.com/mdn/browser-compat-data/blob/fef151c95549aaf56895ee9fa8a332fd418ee98b/api/Element.json#L808-L827 https://github.com/mdn/browser-compat-data/blob/684bc6c638f0dc82bbd660ddf4388792dcdf3eb4/browsers/samsunginternet_android.json#L1-L76

[Elchi3]

Samsung Internet version numbers were added by @poshaughnessy in https://github.com/mdn/browser-compat-data/pull/657. I'm leaving it to the vendors how they want to have their product versions represented in this data set. I'm fine with or without a trailing ".0". Peter?

Chrome and Firefox usually only talk about "55" instead of "55.0", but that's also because there are no major releases like "55.1". This is different for Samsung or QQ. There is "6.0" and "6.2" and so forth. So, maybe this was done to be really explicit when talking about the "6" version releases (so that "6" is really "6.0" and not any "6" release like "6.2").

[ExE-Boss]

Well, at the very least, version_added and version_removed should treat 6.0 and 6 as equal, with how it should be displayed controlled by how the version is named in the browser’s json file.

[Elchi3]

I think this repo benefits from being rather strict and not allowing both 6 and 6.0. I think data querying is a lot easier when there is a canonical version number in the data. And things like automated mass-editing, too. One thing less to worry about imo.

[poshaughnessy]

(Sorry for the slow reply, we're just back from Samsung Create!)

I included the minor version numbers because for us, they can potentially introduce new features / turn them from being behind a flag to switched on by default. (Historically, a minor version upgrade could have even introduced a newer Chromium engine, but we don't do that anymore!). Also, we might have one (e.g. v7.0 now), shipped while the next minor version (e.g. v7.2 now) is still in beta. So I think it makes sense to have separate entries in the browser definition.

I can understand that this will make it a bit trickier for folks to know which version to reference though. Generally it should be a case of just appending ".0" though. Would it help if we do a search for all Samsung Internet entries without the ".x" and add them?

cc: @AdaRoseCannon

[jcsahnwaldt]

I think version numbers should be kept in the format the vendor chooses:

• Samsung version numbers should look like "2.0" (not "2")
• Firefox and Chrome numbers should look like "56" (not "56.0")
• Node.js versions should always be in the format x.y.z, e.g. 10.0.0, 10.2.0, 10.2.1.
  
  
  
  • To most Node.js users, a version number like 10.2 would not be equivalent to 10.2.0, and 10 would not mean 10.0.0.
  
  
  • Node.js always uses full version numbers. See node.green, CHANGELOG_V10.md, etc.
  
  
  • In four recent pull requests for Node.js data, contributors wanted to used full Node.js versions and were surprised they couldn't: #2189 #2262 #2286 #2380 (the title of issue #2379 also mentions a full Node.js version)
  
  

EDIT: @ddbeck collected much more detailed data. Thanks!

[jcsahnwaldt]

What are the advantages (technical or otherwise) of having Node.js versions without trailing zeroes? I don't see any, but I don't know much about this repo and how its data is used.

[jcsahnwaldt]

I'd vote to close this issue.

Sure, it might be nice to have consistent version number formats across browsers, but that's an aesthetic rather than a technical issue, isn't it? I mean, no human or program is going to compare Firefox versions to Samsung versions, so there's no need for them to be compatible.

Of course, they should be internally consistent. For example:

• Firefox version "6" should never be spelled "6.0" or "6.0.0"
• Samsung version "6.0" should never be spelled "6" or "6.0.0".
• Node.js version "6.0.0" should never be spelled "6" or "6.0"

Any code that compares BCD browser version numbers (e.g. a query engine) will have to treat them as something like semver strings anyway (not simply as strings or floats). Otherwise, it won't be able to correctly handle (e.g. sort) versions like "3.6.9" and "50.0.1" (see firefox.json). (This may mean that some code may treat "6", "6.0" and/or "6.0.0" as equal, but it depends on the use case if that's desirable.)

@Elchi3

I think this repo benefits from being rather strict and not allowing both 6 and 6.0.

I'm not sure what you mean. If you mean the repo shouldn't allow both 6 and 6.0 for the same browser, I totally agree. If you mean the repo shouldn't allow 6.0 for browser X while it allows 6 for browser Y, I disagree.

@Elchi3

I think data querying is a lot easier when there is a canonical version number in the data.

Again, I'm not sure what you mean. As far as I can tell, querying version numbers across browsers doesn't make sense (e.g., Firefox 61 doesn't have anything to do with Chrome 61), so there's no need for them to have comparable formats. In other words, users who want to query Samsung versions should use "6.0", users querying Chrome versions should use "6".

@ExE-Boss

version_added and version_removed should treat 6.0 and 6 as equal

I'm not sure what you mean. I guess we agree that for each browser, the repo should only allow one of these formats (e.g. only "6" for Chrome, and only "6.0" (my opinion) or only "6" (your opinion) for Samsung). I guess we also agree comparing version numbers across browsers doesn't make sense (e.g. Chrome 6 doesn't have anything to do with Samsung 6.0). This means that there's no need to treat 6.0 and 6 as equal, because all version_added properties for Samsung will have values like "6.0" (never "6"), and all version_added properties for Chrome will have values like "6" (never "6.0"), and we won't compare Samsung values to Chrome values.

[Elchi3]

I'm not sure what you mean. If you mean the repo shouldn't allow both 6 and 6.0 for the same browser, I totally agree. If you mean the repo shouldn't allow 6.0 for browser X while it allows 6 for browser Y, I disagree.

I meant for the same browser.

Again, I'm not sure what you mean. As far as I can tell, querying version numbers across browsers doesn't make sense (e.g., Firefox 61 doesn't have anything to do with Chrome 61), so there's no need for them to have comparable formats. In other words, users who want to query Samsung versions should use "6.0", users querying Chrome versions should use "6".

I meant again querying data for one browser. So you can query a canonical Fx60 and not Fx60,Fx60.0, Fx60.0.0 etc.

version numbers should be kept in the format the vendor chooses

Yes, I think this should generally be the policy of this repo, so I agree to close this issue and respect Samsung's choice to have trailing zeros. :-) We've made versions strings to allow any format the vendors have. It could even be something like "v4", "version-23-3". It's important to have consistency for a given vendor, but not across vendors / throughout the repo.