We need to figure out how to handle stuff that has landed in Safari’s tech preview builds. We don’t necessarily know for certain what Safari release each item will ship in; they don’t always roll out in the same release as the version number they’re first available in (I think). But we do need to be able to indicate that the thing is there in what are essentially the “nightly” (more like biweekly-ish, but…) builds of Safari.
The trick with Safari, really, is that the release number in the executable (12.1, for example) is not really the number that identifies that preview release. Instead, each preview build has a unique number (for example, this week is Safari Technology Preview 70, with a release number of 12.1). Most of the stuff in TP 70 will be available in 12.1, presumably.
So we have a few things to figure out, and waiting to see if Apple comes along to make these decisions is making it hard to put together fully up to date BCD information for new content.
My questions:
- Do we even want to solve this? Do we keep waiting to see if Apple sets someone up to worry about this?
- Do we just use the release number (12.1, for instance) in BCD and hope it stays there?
- Do we come up with a way to refer to the Tech Preview release instead? If so, is that in addition to or instead of the release number? Like, “version_added”: “12.1”, “preview_number”: “70” or something?
This is all in addition to my previously asked question, which we decided (rightly) to wait on and see if Apple gets involved, back in July: Given that Safari iOS reports its version number as matching the iOS version, not as its own version number, should we switch to using iOS version numbers for Safari iOS?
While waiting to let Apple make these decisions if/when they get into the BCD work has been the right call, at what point does the convenience impact and the inability to provide accurate data override that? I don’t know. Would love to have some discussion.