-
Notifications
You must be signed in to change notification settings - Fork 175
Add guidelines for moving and splitting features #3180
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: v3.0
Are you sure you want to change the base?
Conversation
Now targeting the v3.0 branch. |
You must not do this when the feature has been superseded, such that the feature's name has changed and the exposed behaviors or API surface have changed (in shipping browsers, up to and including unshipping). | ||
Instead, use [`discouraged` data](#discouraged) with one or more `alternatives`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've added some text explicitly noting that redirecting a feature is not how you handle cases like private-network-access
(and local-network-access
) or import-assertions
(and json-modules
).
This was prompted by @foolip asking a good question: would these guidelines would have affected the outcome of #3215? I decided it would not have, but nothing was written down to say (explicitly) why.
Towards #91 and the sequel to #3000.
This PR adds guidelines for redirecting features: moving a feature from one ID or splitting it into multiple other IDs. This is written with the assumption that we'll adopt the schema given in #3000, but the overall gist of it should be the same for any reasonable schema definition.