Decide what to do with pre-37 WebView data

[ddbeck]

Pre-37 WebView questions have come up in several places. I'm trying to narrow the scope and corral the discussion a little with this issue.

The Problem

It's @jpmedley's (and maybe Google's?) position that pre-37 WebView version data is unacceptable in the absence of someone testing features on Android device of the specified version (read #4306 (comment)). If pre-37 versions cannot replace true or null values, then large swaths of features can never have real data.

Background

Our data contains a mix of Android version numbers and Chromium-style version numbers. Before Android 5, Android included WebView as part of the operating system. From Android 5, WebView split into a package shipped and updated independently of the operating system, at which point WebView took on Chromium's versioning. The progression appears to have been:

• Android 4.4 → WebView 30
• Android 4.4.3 → WebView 33
• Android 5 → WebView 36
• WebView 37 onward → whatever Chromium's version number is

Proposals

Some ideas for how this might be resolved. There may be others I've missed.

Hard removal of pre-37 values

As proposed by @jpmedley on #3561. Drop pre-37 WebView entirely. Any WebView values less less than 37 would be hoisted to 37. In other words, we'd act as if WebView only ever had prereleases before 37.

Soft removal of pre-37 values

I'm inventing this idea here. Replace versions before 37 with some kind of catch-all value (e.g., "37 or earlier" or "pre37", depending on how strongly we want to assert features predating 37). This acknowledges WebView's existence before 37, but doesn't actually try to capture the specific versions.

Separate Android-versioned WebView from Chromium-versioned WebView

As proposed by @vinyldarkscratch in #4306 (comment). Bifurcate WebView into a browser for WebView before version 37 (excluding 37 itself) and another for WebView 37 and later.

[ddbeck]

My opinions on these approaches: I'm OK with the first two options, but I'm actively opposed to the third. I would be happy to consider other options.

1. Hard removal is easy, but misleading. It's not congruent with the way Google's own documentation talks about WebView. There exist versions of WebView before 37. It might be Google's position that pre-37 WebView doesn't matter today, but they're also not acting as if WebView didn't release before 37.

2. Soft removal is honest, but quirky. It's a pragmatic option. If we can't figure out what WebView was doing, then a marker of our decision to not bother is a good mix of honest and accurate.

3. I do not want to separate Android-verisoned and Chromium-versioned WebView.

   Foremost, it doesn't solve the problem. Presumably it'd still be Google's position that pre-37 data wouldn't be acceptable (it'd just be unacceptable in a separate field).

   It's unlike what we do for other browsers' name, engine, or operating system distribution changes (otherwise, we'd have separate Presto and Chromium Operas, or a multitude of IEs for the various Windows operating systems). And Google doesn't seem to make a naming distinction (like IE and Edge). What would we even call the two browsers?

   Finally, it's user hostile. For example, to show this data on MDN, there would need to be a second WebView column and we'd need to educate users on what's a very fine distinction about whether or not WebView is distributed as an APK.

[jpmedley]

I'm in favor of soft removal. I was about to suggest something similar. My idea had been to take advantage of the ability of __compat members to accept an array and do something similar to what we do with prefixes. This is not a proposal. Daniel's idea is simpler.

[queengooborg]

I think soft removal is the simplest method while satisfying all the issues we face. Originally I was leaning towards hard removal (I never liked the idea of separating the two browsers, I just recall it was mentioned in this repo at some point), but like you're saying, hard removal acts as if those browser versions never existed.

So, my vote's on soft removal!

[ddbeck]

@Elchi3 I'd like your take on this, when you're back

[ExE-Boss]

The soft removal would be doable with #3881.

[Elchi3]

Thanks for this issue, great stuff!

I also think soft removal makes most sense. I think @ExE-Boss is right that if we go down the soft removal road, it's similar to what we've discussed in #3021. Exe-Boss has proposed "<=" as a syntax for this in #3881 whereas this issue seems to propose "pre".
So, I think we should try to have one concept as I think it is about the same thing in the end. In fact, the webview pre37 case presented here, looks to me as if it could just one case of the whole idea behind #3021. Does that make sense?

[ddbeck]

@Elchi3 and I had a chat about this today. I'm going to try to recap our discussion here.

Florian is right that the pre-37 proposal here is one specific case of the principle of #3021-style feature ranges. I expressed some discomfort with introducing feature ranges across all of BCD; it would require us to come up with a broad range of new standards about version data (e.g., when is a feature range good enough to merge versus demanding a specific version). Florian suggested a good compromise: restricting the use of feature ranges to certain browsers and versions. He and I agreed that WebView could be a good test case for this (similarly, early Safari versions might also represent good cases to try this with).

With that in mind, I suggest that Florian and I take a look at #3881 and see if that could be used to solve this problem (assuming @ExE-Boss is amenable). If we were to use the <= syntax, then we could probably use <=37 for pre-37's soft removal (i.e., hoist all WebView data before 37 to <=37).

@Elchi3 if I've misrepresented anything here, please correct the record. 😄

[jpmedley]

Florian's compromise also makes sense to me. Because I don't know how the <= syntax affects other browsers, but I do know exactly how it affects WebView and I think it solves the problem. (Rather, from a practical standpoint, it as good as solves it.)

[chrisdavidmills]

This also sounds fine to me, and follows the train of thought I was on for this. To do this across all of BCD would be difficult, time consuming and unnecessary. We should only do it for specific browser ranges where we really need it.

[Elchi3]

This sounds all very good to me, @ddbeck! Thanks for capturing our discussion. I think I will close #3881 and #3021 as we should decide what to do per browser and not allow ranges everywhere throughout the data. So, this issue is now specifically about webview_android and what kind of range we want to allow. Let's have new issues for other browsers, please.

One general question remains, though:

• Will we add "<=37", "pre-37", or "pre37" as an allowed string for webview_android in version_added/version_removed?

And then, for webview_android, I still see some options on the table which we should discuss:

• Do we really want to hoist real values ("Android 4.4" etc.) to "pre-37" when these are already more precise than "pre-37". Is the hoisting really necessary?
• Instead of hoisting everything earlier than 37 to "pre-37", can we just hoist "true" to "pre-37"?
• If someone comes along with a PR and has an excellent proof that something was in say Android "4.2", will we then allow the change from "pre-37" to "4.2". Why wouldn't we allow this more precise data?

[ExE-Boss]

I’d prefer if we keep #3881 and #3021 open as a general purpose temporary solution for getting rid of true values.

[jpmedley]

Do we really want to hoist real values ("Android 4.4" etc.) to "pre-37" when these are already more precise than "pre-37". Is the hoisting really necessary?

I would say don't hoist.

Instead of hoisting everything earlier than 37 to "pre-37", can we just hoist "true" to "pre-37"?

I agree.

If someone comes along with a PR and has an excellent proof that something was in say Android "4.2", will we then allow the change from "pre-37" to "4.2". Why wouldn't we allow this more precise data?

I agree.

[Elchi3]

Seems like we're decided. Filed #4479 to get this work done in the next sprint.