Major version up when the first logic change happens e.g. introduction of __globals

[saschanaz]

From #11518 (comment)

The mapping from IDL to BCD item breaks when such new logic emerges.

[Elchi3]

I'm still not entirely sure what this means practically.

In #11518 (comment) @foolip says "The problem is basically how to create a mapping between Web IDL and BCD paths."

Maybe this suggests that https://github.com/mdn/browser-compat-data#Semantic-versioning-policy should be updated to also take into account "problems with Web IDL and BCD paths" (where "problems" would need to be defined further).

[saschanaz]

Not sure how to define it, but roughly, introducing a new logic to move items into different places. (e.g. mixins to __mixins, global items to __globals, etc.)

[ddbeck]

What's the breaking change we want to key on, exactly? Because the existence of __globals isn't transparent to package consumers.

Perhaps the right idea is to commit to increasing the number of features (e.g., everything at the level of api.*) that trigger SemVer major releases? Or introduce something to the schema to explicitly mark SemVer-protected/ignored features? Or go all out and say that any time we remove a feature, that's a breaking release?

[saschanaz]

Well, I think it should be about the logic rather than each change.

Say there is interface mixin FooMixin included by interface Foo. For pre-4.0 bcd was expected to have both api.FooMixin and api.Foo, and tools could refer to api.FooMixin for mixin members. For post-4.0 the mixin data is merged to api.Foo, which means tools need a corresponding logic to find mixin member data from api.Foo, by e.g. collecting inclusion declarations (Foo includes FooMixin;). After the new logic is implemented, further removal of mixins will not break that tool.

Same for _globals. For pre-4.0.2 bcd was expected to have api.WindowOrWorkerGlobalScope.isSecureContext but it's now api.isSecureContext, so the tools need to detect a mixin is included by globals (again by tracking inclusion declarations) and find the data for WindowOrWorkerGlobalScope members from api instead of api.WindowOrWorkerGlobalScope to . Further change will not break the tool after adding such logic.

So the issue is all about automation and I have no interest for any progressive data changes after the initial logic shift.

[ddbeck]

OK, that makes sense. I'm trying to figure out how to turn that into an easier set of yes/no conditions that trigger a new version and I think I've got it, in a slightly roundabout way:

We could SemVer major whenever a new data guideline requires obligates features to move (or be removed).

This would impose some new obligations (we'd probably need to write guidelines earlier in the process for these sorts of changes), but would provide a clearer point to initiate a version bump.

[saschanaz]

#13884 is technically also a breaking change. Projects depending on the previous on* access should invent a new way to get support data for those attributes.

[queengooborg]

I'm going to close this issue because we haven't really had a big move of features in a long while, at least nothing that would be covered by this issue.