Scrub Safari Technology Preview from notes

[ddbeck]

We ought to drop the handful of notes which document quirks of Safari Technology Preview versions. As a rule, we don't document patch-level version changes to browsers (refer to the guideline for this). Instead, we should make a judgment about the likelihood of something reaching a significant Safari release (in the case of Safaris in beta) or defer merging such data until we can make a judgment.

At the time I opened this issue, I found seven such notes: two in api/Worker.json and six in javascript/builtins/intl/Locale.json (found with rg -i 'technology.preview').

Related to #6448 and #6440 (and more historically #2709, though that may have been before we had a clearer idea of how we wanted to handle this sort of thing).

cc: @wopian, @sideshowbarker

[sideshowbarker]

I’ve assumed that the notes are meant to be helpful for developers who are intentionally choosing to target Safari Technology Preview and its users, in the interim until the next major Safari release.

However, if our policy is that we explicitly should not attempt to provide such information to that set of developers, then I’m on board for that, and (going forward) will — when doing PR reviews — flag for removal any notes that don’t follow the policy.

[ddbeck]

"Scrub" is probably overstating my case a bit, to be honest. I'd say we should strive to reflect what a given Safari version (or other browser) ships, rather than the development of that version.

I think TP releases are somewhat analogous to the way we treat nightlies or betas: we want to record what the browser will look like when it's actually released at that version number, not every stop in between. In an ideal world (at least for the purposes of BCD), Apple would tell us how a TP number maps to a Safari release (e.g., Safari TP X = Safari 14, Safari TP X+30 = Safari 14.1, and so on). Without that, we probably have to make predictions or be circumspect or both.

To use one of these recent changes as an example, if we're certain that Safari TP 112 is going to be subsumed by Safari 14—if we're certain that the fix to the Intl.Locale return value will be such that the generally released Safari 14 "always" returned the correct value—then we should probably omit the note. If we're not certain (very plausible!), then we should probably couch it in such terms. For example, we might say something like:

This method returns a string instead of a Locale object. Safari 14 Technology Preview 112 fixes this bug; this fix may be reflected in the final release of Safari 14.

[ddbeck]

Also, to add one last note here: I'm open to approaching this other ways, too. There's probably more creative solutions (linking to BCD's own GitHub issues, maybe?) that I haven't thought through. 😃 The real thing I'm trying to avoid is baking information into BCD that immediately goes out of date, gets forgotten, and never cleaned up.

[sideshowbarker]

In an ideal world (at least for the purposes of BCD), Apple would tell us how a TP number maps to a Safari release (e.g., Safari TP X = Safari 14, Safari TP X+30 = Safari 14.1, and so on). Without that, we probably have to make predictions or be circumspect or both.

Hopefully we’ll get there eventually — the recent increased participation here from some core Safari folks has been encouraging

The real thing I'm trying to avoid is baking information into BCD that immediately goes out of date, gets forgotten, and never cleaned up

100% agreed on optimizing to avoid that

[wopian]

As a rule, we don't document patch-level version changes to browsers (refer to the guideline for this)

I took that as referring to the version property when reading the guidelines. I added the 107-110 (111) note as it was a specific quirk to a few tech previews that had non-standard behaviour. It may have been better to of used partial_implementation: true instead since it didn't release in 111 as I had anticipated (and hoped for)

---

Apple would tell us how a TP number maps to a Safari release (e.g., Safari TP X = Safari 14, Safari TP X+30 = Safari 14.1, and so on). Without that, we probably have to make predictions or be circumspect or both.

This is why I put the exact TP releases in #6440 as I didn't know how the tech previews mapped to the beta releases - Big Surr is apparently on Beta 3 right now but I can't find any information of what Safari beta version its shipping, presumably a "Beta 3", but again there's no information about what TP/WebKit revisions those betas relate to and I don't have an Apple device that would be able to investigate.

From #6640:

Safari 14 is currently only in a beta phase and I do not use an Apple product/Safari myself, so I don't know how the Technology Previews map to actual Safari versions so they may need changing?

---

The real thing I'm trying to avoid is baking information into BCD that immediately goes out of date, gets forgotten, and never cleaned up

I think this was why I added it as implemented with a note instead of using partial_implementation: true as the fix had already landed in the trunk and 14 is still several months from a stable release/Big Sur release. It was just unfortunate the TP 111 release and the merge happened in a short timeframe so I wasn't aware it had missed the TP 111 release and would instead land in TP 112.

---

To use one of these recent changes as an example, if we're certain that Safari TP 112 is going to be subsumed by Safari 14—if we're certain that the fix to the Intl.Locale return value will be such that the generally released Safari 14 "always" returned the correct value—then we should probably omit the note. If we're not certain (very plausible!), then we should probably couch it in such terms. For example, we might say something like:

This method returns a string instead of a Locale object. Safari 14 Technology Preview 112 fixes this bug; this fix may be reflected in the final release of Safari 14.

Big Sur and Safari 14 is likely a September/October release (every release has been since 2013). The macOS/iOS betas have been roughly every 2 weeks which aligns with the Technology Previews at least so I think it's safe to assume it'll be in the general release of Safari 14.

I'd be happy to change the notes to that or something that matches the wording of the Node 13 notes such as:

Prior to Safari 14 Technology Preview 112, this method returns a string instead of a Locale object; the fix may be reflected in the final release of Safari 14.

Prior to Safari 14 Technology Preview 112, the minimize and maximize methods return a string instead of a Locale object; the fix may be reflected in the final release of Safari 14.

---

The recent increased participation here from some core Safari folks has been encouraging

I don't have any affiliation with Safari unfortunately - I just happened to implement Intl.Locale for an (accurate) locale fallback for automatic localisation* of an open source service I contribute to around the same time the Safari 14 betas came out with Intl.Locale support.

* I.e. a Mexican (es-mx) user sees Spanish (es-es) if es-es is translated but their primary locale es-mx is not.

I’ve assumed that the notes are meant to be helpful for developers who are intentionally choosing to target Safari Technology Preview and its users, in the interim until the next major Safari release.

I wasn't aware Safari 14 supported Intl.Locale at all at the time and I had only implemented guards against Intl and Intl.Locale not being supported, so all was well and good until I released it to a handle of beta testers which happened to have included a bunch of Big Sur and iOS beta users 😞

…and then had the fun experience of discovering the issue some macOS users were having was due to the Safari betas actually supporting the API and passing the guard checks, but attempting to access a non-existent property of a string instead of a property of the Locale object as expected.

---

This turned out to be rather long, but overall I somewhat agree but I would be against omitting the note in its entirely until Safari 14 has a public release as others shouldn't need to go through hoops like I did to find and guard against the early non-standard implementation (more non-dev oriented Apple users use TP than I expected). I'm all for changing the notes to the following if this would be preferred:

min/max methods: Prior to Safari 14 Technology Preview 112, this method returns a string instead of a Locale object; the fix may be reflected in the final release of Safari 14.

Locale: Prior to Safari 14 Technology Preview 112, the minimize and maximize methods return a string instead of a Locale object; the fix may be reflected in the final release of Safari 14.