[webkit-dev] Deprecating features guideline wiki

[Julien Chaffraix]

>>> 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
>>> removal.
>>>
>>> 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
than deprecation.

>>> 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'
>>> reactions."
>>>
>>> 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
>>> answer?

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
vendors API.
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.

Julien