In practice, it is difficult to test whether a feature was first introduced in a major version (eg 12) or a minor version (eg 12.1) of Safari and Safari for iOS. Local testing is impeded by the dependence on the operating system, making it impossible to switch between two versions on the same physical machine, as well as the absence of Windows, Linux and Android editions. Similarly, cloud services such as Browserstack tend to remove older major versions once a newer minor version becomes available. It is possible to find this information by examining the source but not everyone has the time and knowledge to do this; even those who do can easily make mistakes when it comes to flags and preferences. The changelogs, while sometimes useful, are often incomplete and not in-depth for developers.

Without this effort, it is impossible to quickly and accurately submit known data for Safari. Contributors are forced to submit data with the version set to either true or null or simply just assume the feature was released in the major version. (An assumption that is not always true!) This reduces the accuracy and usefulness of the data. This level of precision and accuracy is still useful to have, however, especially for major versions that precede the current release and minor versions that succeed the current release.

As an alternative, I propose that contributors should be able to submit ranges such as 12-12.1 or 12.x for Safari and Safari for iOS. Ranges that cross major versions, such as 12-13, remain disallowed. This is still more specific than existing ranges such as ≤18 and ≤79 for Edge but, for ranges where all versions are retired, almost as useful as full data.