[webkit-dev] New status field required for feature flags

[Jean-Yves Avenard]

Hi.

What status should be used for:
"Enabled by default on most platforms except those we’ve decided not to support or if a local system dependency can’t be met but feature is still ready for general use, but UI to toggle the feature remains to support debugging, A/B testing."

That defaultValue could be ignored in the future seems a regression and doesn’t address some existing use cases.

Thanks
Jean-Yves

> On 10 Jan 2023, at 9:11 am, Elliott Williams via webkit-dev <webkit-dev at lists.webkit.org> wrote:
> 
> Hi webkit-dev,
> 
> Brent (CC’d) and I are rolling out changes to how we represent feature flags in WebKit. As of https://commits.webkit.org/258448@main, the WebPreferences*.yaml files have been merged to one feature list:
> 
> 	Source/WTF/Preferences/UnifiedWebPreferences.yaml
> 
> Instead of having separate lists of experimental features, internal debug features, etc., each feature now has a `status` field. A feature’s status determines which UIs it is visible in (if any), and in the future will control its default value. Right now, these are the semantic meanings of the features status:
> 
> 	embedder	Adjust WebKit behavior for embedding application needs.
> 	unstable	Feature in active development. Unfinished, no promise it is usable or safe.
> 	internal 	Tools for debugging the WebKit engine. Not generally useful to web developers.
> 	developer	Tools for web developers.
> 	testable	Enabled by default in test infrastructure, but not ready to ship yet. Should be accessible for STP users who wish to activate them for testing and feedback.
> 	preview	Enabled by default in Safari Technology Preview, but not considered ready to ship yet.
> 	stable	Enabled by default and ready for general use, but UI to toggle the feature remains to support debugging, A/B testing.
> 	shipping	Enabled by default and ready for general use, but no UI to toggle. In general, will be removed 1 year after the change to shipping.
> 
> When you’re adding or changing features, our source generator will force you to pick one of these status. The “public-facing” statuses (developer, testable, preview, stable) are visible from the various “experimental features” call sites declared by WebKit, and the rest are exposed as “internal debug features”. And I’m adding an additional WebPreferences API which lists all features, so clients can avoid the experimental/internal-debug dichotomy going forward.
> 
> There’s one topic I’d like feedback on, which pertains to the non-Apple ports:
> 
> Some features don’t seem to have the same “status” on all platforms. For example, pdf.js has been enabled for GTK and WPE for some time now, and should probably be considered `stable` on those platforms. But it’s off by default on Apple platforms, where it should be no more than `testable`. How do we resolve discrepancies like these? We could:
> 
> - allow a feature’s status to be platform-conditional
> - allow each port to decide whether a feature is on or off by default (regardless of its status)
> - do nothing, and require clients to change feature statuses at runtime in order to modify default behavior
> 
> I’d like to eventually use the committed feature list to power https://webkit.org/status/, which makes me want to avoid having platform-conditional statuses. It would also be nice for feature statuses to be a global truth, helping us speak collectively about what web platform features are supported.
> 
> Elliott
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3643 bytes
Desc: not available
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20230111/c1f2cc5a/attachment.bin>