Title: [199555] trunk/Websites/webkit.org
- Revision
- 199555
- Author
- [email protected]
- Date
- 2016-04-14 14:37:04 -0700 (Thu, 14 Apr 2016)
Log Message
Publish the Web-exposed feature policy on webkit.org.
https://bugs.webkit.org/show_bug.cgi?id=156552
Patch by Edward O'Connor <[email protected]> on 2016-04-14
Reviewed by Timothy Hatcher.
* feature-policy.md: Added.
Modified Paths
Added Paths
Diff
Modified: trunk/Websites/webkit.org/ChangeLog (199554 => 199555)
--- trunk/Websites/webkit.org/ChangeLog 2016-04-14 21:21:57 UTC (rev 199554)
+++ trunk/Websites/webkit.org/ChangeLog 2016-04-14 21:37:04 UTC (rev 199555)
@@ -1,3 +1,12 @@
+2016-04-14 Edward O'Connor <[email protected]>
+
+ Publish the Web-exposed feature policy on webkit.org.
+ https://bugs.webkit.org/show_bug.cgi?id=156552
+
+ Reviewed by Timothy Hatcher.
+
+ * feature-policy.md: Added.
+
2016-04-13 Jon Davis <[email protected]>
Remove database quote escapes from pushed tweets.
Added: trunk/Websites/webkit.org/feature-policy.md (0 => 199555)
--- trunk/Websites/webkit.org/feature-policy.md (rev 0)
+++ trunk/Websites/webkit.org/feature-policy.md 2016-04-14 21:37:04 UTC (rev 199555)
@@ -0,0 +1,63 @@
+### Runtime flags
+
+Generally, new author-facing features should be implemented behind
+**runtime flags**. Initially, such flags should be disabled on trunk. As
+work on a feature matures, its flag may be enabled on trunk. Eventually,
+runtime flags guarding widely deployed, stable features should be
+removed.
+
+The following criteria define when runtime flags should be enabled or
+disabled **on trunk**. This policy is not intended to embody or
+communicate a feature release policy for any particular WebKit port or
+product which embeds WebKit. It is the responsibility of each port to
+determine if or when runtime flags should be enabled or disabled for
+release. Ports are encouraged to document any additional criteria they
+may use.
+
+In some cases, compile time flags should be used in addition to or
+instead of runtime flags:
+
+* When merely compiling a feature in significantly impacts the
+ hackability or livability of trunk.
+* When a feature requires a platform-specific backend that is not
+ available on all platforms.
+* When some ports or platforms have resource constraints which require
+ the ability to remove the feature completely from builds.
+* When a feature is otherwise only relevant to some ports or platforms.
+
+That said, runtime flags are preferred whenever feasible.
+
+A runtime flag should be **disabled on trunk**:
+
+* When work on the feature begins.
+* When the feature is not intended to be Web-exposed.
+* When the feature is defined in a Web standard which is immature or is
+ likely to incompatibly change.
+* If enabling the feature would negatively affect the livability of
+ trunk. (In such cases a compile-time flag may also be warranted.)
+
+Later, a runtime flag may be **enabled on trunk**:
+
+* When the feature is defined in a mature Web standard which is
+ unlikely to incompatibly change.
+* If the implementation of the feature is relatively mature and it is
+ ready for wider testing or review.
+* If support for the feature is required for Web compatibility.
+
+Eventually, a runtime flag may be removed and the feature made **always
+on**:
+
+* When most or all major ports of WebKit are shipping the feature and
+ none plan to turn it off.
+
+### Naming
+
+In general, new features **should not be prefixed**.
+
+A new feature **should be prefixed** if the feature is not intended to
+be Web-exposed. (And, as established in the previous section, such
+a feature's runtime flag should be disabled on trunk.)
+
+A prefix specific to the product or content type is preferred over the
+`-webkit-` prefix. For example, a feature intended for FooCorp's
+flagship Foo product should get a `-foo-` prefix, not a `-webkit-` one.
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
