[webkit-dev] Deprecating features guideline wiki
jchaffraix at webkit.org
Mon Apr 30 07:55:11 PDT 2012
>>> BTW, the page at <https://trac.webkit.org/wiki/DeprecatingFeatures> seems
>>> to be using "deprecate" in the sense of "remove entirely". Is that what is
>>> meant? If so, I think it would be helpful to change the wording to "removing
>>> features". In non-Web contexts, deprecate often means a step short of
>>> I agree that "Removing features" is clearer and more to the point :).
>>> When to deprecate features in the sense of "we recommend you use this
>>> other feature instead" is an entirely different conversation.
I will make the change as people seem to prefer talking about removal
>>> Now that I look closer, I see that it says:
>>> "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'
>>> This seems to imply that there actually is a step of deprecation that
>>> comes prior to removal. What exactly is this step? How are features supposed
>>> to be marked deprecated? What is the effect of being deprecated, if any,
>>> other than future removal? Does anyone who was at the session know the
This is unfortunately something that we didn't discuss much. Our
current way is to display something on the console as Ryosuke pointed
out, which is easy but likely not optimal.
>> I'd assume this is something like outputting a warning in the
>> console. (Disclaimer: I didn't attend this session.)
>> That sounds plausible, but I'm hoping to hear from someone who attended
>> the session to say for sure. If "deprecate" means console warning, followed
>> by removal later, then I'd suggest we go straight to removal.
I have one issue with that. First this proposal assumes that the
feature is not exposed in someone's API. For such features, we will
need to have a deprecation step as it needs to be removed from every
More to the point, deprecating gives us a safety net in case we missed
something during our data gathering (an example I can think of are
intranets or internal apps that may be using the feature).
> Outputting console warnings prior to a feature removal appears to be a
> common practice (e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=749920).
> I'm also afraid that not giving any advance notice for features that have
> some users like mutation events might be perceived badly by developers.
> On the other hand, I'm certain we don't need to output console warnings if
> we're removing features nobody uses (e.g. support for khtml prefixes for
> recently added CSS properties).
> So we probably can't (and shouldn't) make a unilateral policy here.
Seems like a good balance to give some leeway on whether we should
have a deprecation step or not.
More information about the webkit-dev