Changes between Version 5 and Version 6 of DeprecatingFeatures

Timestamp:

Sep 21, 2012, 3:13:01 PM (12 years ago)

Author:

abarth@webkit.org

Comment:

--

DeprecatingFeatures

@@ -5 +5 @@
 = Balancing costs and benefits =
 
-The guiding principle in our approach is to balance net costs of removing the feature against the net costs of retaining the feature.  In many cases, evaluating these costs is a value judgement, and whenever possible, we should strive to replace opinion with data.  The following are a number of factors we ought to consider when removing a feature:
+The guiding principle in our approach is to balance net costs of removing the feature against the net costs of retaining the feature.  In many cases, evaluating these costs is a value judgement, and whenever possible, we should strive to replace opinion with data.  The following are some factors we ought to consider when removing a feature:
 
  * ''Compatibility.''  The more a given feature is used, particularly on the web at large but also in "walled gardens" of content, the larger the compatibility cost of removing the feature.  For example, we have not removed our implementation of [http://www.w3.org/TR/webdatabase/ SQLDatabase] even though other browser vendors have refused to implement the feature and the W3C has removed the specification from the standards track.  We've kept SQLDatabase because removing this API would break compatibility with a large number of consumers of WebKit that use this API.
@@ -11 +11 @@
  * ''Interoperability.''  If a feature fails to garner wide-spread implementation, then web sites that use that feature might work in one user agent but not in another.  This lack of interoperability fractures the web platform, making it more difficult for users to switch from one user agent to another.  Removing WebKit-proprietary features, or at least hiding them from the web platform, often improves interoperability.
 
- * ''Complexity.''  Each feature we include in WebKit increases WebKit's complexity, slowing down development of the engine.  We try to reduce the complexity cost of features, for example by using [[Modules]], but each feature still adds a non-zero cost (e.g., for project-wide improvements, like [[EfficientStrings]]).  Remove a feature often reduces the complexity of WebKit.
+ * ''Complexity.''  Each feature we include in WebKit increases WebKit's complexity, slowing down development of the engine.  We try to reduce the complexity cost of features, for example by using [[Modules]], but each feature still adds a non-zero cost (e.g., for project-wide improvements, like [[EfficientStrings]]).  Removing some features (e.g., Workers) reduces the complexity of WebKit greatly, whereas removing others (e.g., Blob.webkitSlice) has little impact on WebKit's overall complexity.
+
+= Approaches for removing features =
+
+There are a number of different approaches you can use to remove features from WebKit.  Similar to [http://www.webkit.org/coding/adding-features.html adding features], it's important to communicate clearly with the WebKit community.  Often emailing [http://lists.webkit.org/mailman/listinfo/webkit-dev webkit-dev] is a good place to start.  In your email, you will likely want to outline which feature you'd like to remove, the relative costs and benefits of removing the feature, and which of the following approaches you intend to take.
+
+== Cold turkey ==
+
+== A port-specific experiment ==
+
+== Measure, deprecate, and remove ==
+
+= Special considerations for vendor prefixes =
 
 = XYZZY =
-
-= How to determine if we can deprecate a feature =
-
- * The burden on the overall project needs to be evaluated as it should be the primary driver for dropping any feature. Small features that require very little maintenance may not qualify under this rule and their deprecation would need to be argued extensively.
- * If the feature is used (e.g. MutationEvent), we need to show that we have a replacement that is '''better''' than the feature to be deprecated (better needs to be defined in the context of the deprecation and will need to be argued).
- * Deprecating a feature means we will remove it in the future. Deprecation is not meant as a usage metric collection or to assess web-developers' reactions.
 
 = Deprecation steps =