Part 1 of 2: copy feature policy to permissions policy.

[jpmedley]

PLEASE READ CAREFULLY. A unique problem requires a unique approach, which is described below.

The rename of 'Feature Policy' to 'Permissions Policy' requires that BCD be moved as well. Regardless of whether BCD is changed before MDN content or vice-versa, there will be a stage where BCD keys in MDN documents will point to data that isn't there. To get around this, I have duplicated the data. In other words, when this is deployed there will be data under the keys Feature-Policy and Permissions-Policy. This is by design. When the new MDN pages are deployed, I'll come back remove the data recorded under Feature-Policy.

mdn/content#1831

[ddbeck]

I'm not comfortable with this approach. My major concerns are:

• This is not consistent with how we've fixed most other cases where BCD's using a historic (or simply incorrect) name. We've had pretty good success with renaming things in BCD and holding the PR open until there's a PR in progress to make the corresponding changes on MDN.

• This doesn't actually duplicate the data; it creates a set of separate, inconsistent data points and no plan to maintain them in the interim. If this PR were to be merged, then Feature-Policy data would duplicate only part of the Permission-Policy data, while the Permission-Policy data would duplicate all of Feature-Policy. At very least, the Feature-Policy data would need to be updated with alternative_name statements to create symmetry with the Permission-Policy data.

• To write the release notes for this, I'm going to have to track every feature rename manually. That is, I'll have to track the addition of these features, then the removal of the other features, and line them up to each other. This is going to create a ton of busy work. For me, most likely. 😅 I've got tools to handle direct renames, but not this.

[jpmedley]

What lead me to this was the large number of pages that would contain missing BCD and the unknown amount of time needed to correct it. I'm working as quickly as I can to keep that time short, but I expect the review process to be tedious and somewhat drawn out. To help, I've already split the affected pages into 4 separate PRs which I recommend merging in close proximity. The PR to remove the duplicate content would be removed as soon as the updated files are deployed.

I would suggest that any changes to this data go exclusively to the replacement key: permissions-policy.

If you have a better idea, I'm all ears.

[jpmedley]

I've opened four PRs to replace 'feature policy' with 'permissions policy'. I believe this is all of the content that needs to be updated.

[foolip]

Was support for the Feature-Policy header really removed, one release before its replacement even?

[hamishwillee]

Strictly speaking, a spec rename should be accomplished by renaming the feature-policy json to permission policy, updating the content, and adding an alternative name. However I don't think BCD can properly represent the relationship using alternative names because these can't be fully qualified - as a result it might become quite messy to indicate the things that do and do not have an alternative name as the spec evolves.

Proposal: We treat Feature-Policy and Permission-Policy as separate technologies at the BCD level. Practically speaking this means that this PR would be modified to:

• have start dates based on when Permission-Policy actually appeared
• also modify Feature-Policy with end-dates for support on any browsers that stopped using this name and do not support it as an alternative name.

If we treat them as separate implementations then the versioning can be presented very clearly. The only issue we'd have is whether we "try" to present alternative names at all. I'd say "not".

@ddbeck FYI

[ddbeck]

@jpmedley I'm going to close this PR, since the corresponding content PRs have also been closed. Feel free to open a new one with the additions of permissions policy, but let's treat feature policy and permission policy as two closely related but distinct features. Thank you!