Hey blink-dev, Within Google we’ve had a lot of discussion over the past year about how we should make increasing use of flags and kill switches <https://chromium.googlesource.com/chromium/src/+/main/docs/flag_guarding_guidelines.md> to reduce the risk of breaking changes, but I realized there hasn’t been discussion here on blink-dev.
Once a change hits stable it’s quite expensive and time-consuming to do an emergency patch, but much faster and cheaper to update a server config. For Google Chrome this means “Finch”, but other big chromium embedders like Edge also have their own system for setting flags dynamically. So increasingly we want to ensure that changes which might reasonably cause a regression are guarded by a flag wherever practical. For Blink this simply means using a Runtime Enabled Feature <https://chromium.googlesource.com/chromium/src/+/main/third_party/blink/renderer/platform/RuntimeEnabledFeatures.md#:~:text=Features%20that%20are%20hidden%20behind,To%20Ship%20has%20been%20approved.> (or other base::Feature). I think we’re all largely in the habit of using this for new APIs, but we should also be using one for all intentional breaking changes and this is something the API owners will be asking about. See Flag Guarding Guidelines <https://chromium.googlesource.com/chromium/src/+/main/docs/flag_guarding_guidelines.md> for more details and feel free to reach out to me and/or [email protected] with questions or concerns. Thanks, Rick -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9iR-n102RPZWfqpUGjYm9W2LpFFb5%2BodimGFUC8Dv8ZA%40mail.gmail.com.
