> On Nov 5, 2016, at 6:18 PM, Michael Catanzaro <mcatanz...@igalia.com> wrote: > > On Sat, 2016-11-05 at 16:03 -0700, Ryosuke Niwa wrote: >> Maybe what we really need is one set of defaults that are appropriate >>> for development (our bots, ENABLE(DEVELOPER_MODE), Safari Tech >> Preview, >>> etc.) and a different set of defaults that are appropriate for >> stable >>> releases and end users. >> >> >> That makes sense. Ideally, >> FOR_EACH_WEBKIT_EXPERIMENTAL_FEATURE_PREFERENCE >> is only used for features that need to be enabled in those "beta" or >> "developer" versions of each port's browser. > > Yeah, it could be as simple as all those experimental features are > enabled by default in the ENABLE(DEVELOPER_MODE) case, and they're all > disabled otherwise. Though then there's no way to have features > runtime-enabled features that are too unstable even for Tech Preview. > > All CMake ports support ENABLE(DEVELOPER_MODE); is that defined > anywhere with the XCode build?
I still don't think this is right. Safari might want to enable a "disabled by default" feature for a release, or it might want to disable an "enabled by default" feature for a release. We'd do so by changing the default value in the code and then checking that in to our branch for that release. In this same vein, "trunk" is a "branch" for a certain type of release (WebKit nightly, STP, etc) where I think there's arguments to be made on a per-feature basis that it be either disabled or enabled by default. Thanks, ~Brady _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
