Disallow consecutive partial_implementation statements on same track

[caugner]

What type of issue is this?

Infrastructure issue

What is the issue?

The linter did not complain about multiple consecutive support statements with partial_implementation: true:

browser-compat-data/api/GPU.json

Lines 35 to 57 in d8cf057

	"firefox": [
	{
	"version_added": "147",
	"impl_url": [
	"https://bugzil.la/2004105",
	"https://bugzil.la/1942431"
	],
	"partial_implementation": true,
	"notes": "Supported on Windows and macOS on Apple silicon, in all contexts except for service workers. On other platforms the interfaces are exposed but are not accessible (`GPU.requestAdapter()` returns `null`)."
	},
	{
	"version_added": "145",
	"version_removed": "147",
	"partial_implementation": true,
	"notes": "Supported on Windows and macOS Tahoe on Apple silicon, in all contexts except for service workers."
	},
	{
	"version_added": "141",
	"version_removed": "145",
	"partial_implementation": true,
	"notes": "Supported on Windows only, in all contexts except for service workers."
	}
	],

What behavior were you expecting?

In these cases, a single partial_implementation should be used, with notes explaining the different progression.

What version(s) of BCD is the issue present in?

• The current BCD release
• The current version of the main branch

Do you have anything more you want to share?

Noticed in this PR.

[ddbeck]

By my reading, these are different partial implementations (i.e., there's no partial state that is continuous from version 141-146, inclusive). Can you show the JSON you'd expect to see here?

[caugner]

Can you show the JSON you'd expect to see here?

browser-compat-data/api/GPU.json

Lines 35 to 46 in 75aea8a

	"firefox": {
	"version_added": "141",
	"partial_implementation": true,
	"notes": [
	"Supports all contexts except service workers. See [bug 1942431](https://bugzil.la/1942431).",
	"Supports Windows since Firefox 141. See [bug 1972486](https://bugzil.la/1972486).",
	"Supports macOS Tahoe on Apple silicon since Firefox 145. See [bug 1992212](https://bugzil.la/1992212).",
	"Supports older macOS versions on Apple silicon since Firefox 147. See [bug 1993341](https://bugzil.la/1993341).",
	"Does not support macOS on Intel CPUs. See [bug 2004105](https://bugzil.la/2004105).",
	"Does not support Linux. See [bug 2006676](https://bugzil.la/2006676)."
	]
	},

We had similar consecutive partial statements in MLGraphBuilder, see: https://github.com/mdn/browser-compat-data/pull/28133/changes#diff-aa4eccc182a449b9e6ab3c97fc55f092516bcf4f1877d7b269aa03283f0f6078R102

[ddbeck]

I'm not sure WebNN is a good example. In that case, the behavior is always behind a flag and our behind-a-flag data is lower effort. In this case, the set of supported devices changes across multiple stable releases. I think it makes sense to have separate statements, when support widens over time. In a simpler example, I'd expect two consecutive partials if support went from Windows-only, to Windows and mac, and (finally) to Windows, macOS, and Linux without a partial.

(Though I could've sworn we talked about this requestAdapter thing in the past—the browser's allowed to return null kinda arbitrarily. 147 plus might actually be non-partial?)

[caugner]

I think it makes sense to have separate statements, when support widens over time. In a simpler example, I'd expect two consecutive partials if support went from Windows-only, to Windows and mac, and (finally) to Windows, macOS, and Linux without a partial.

This is where we disagree. I think a single partial statement is both easier to maintain, and easier for users to read.

--

Edit:

(Though I could've sworn we talked about this requestAdapter thing in the past—the browser's allowed to return null kinda arbitrarily. 147 plus might actually be non-partial?)

Yes, we'll tackle this in a separate PR. It also affects Chrome.