[webkit-dev] Deprecating features guideline wiki

[Maciej Stachowiak]

On Apr 29, 2012, at 1:18 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:

> On Sun, Apr 29, 2012 at 1:08 PM, Maciej Stachowiak <mjs at apple.com> wrote:
> On Apr 29, 2012, at 1:04 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
>> On Sun, Apr 29, 2012 at 12:37 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>> 
>> On Apr 27, 2012, at 6:29 PM, Dirk Pranke <dpranke at chromium.org> wrote:
>>>> 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.
>> 
>> 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?
>> 
>> 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.
> 
> 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.

I agree that it's a good idea to give content authors due notice. But I don't think a console warning is a very good way to do it. I think most authors pay no attention to console spam. A blog post would probably reach more authors successfully than a console warning.

Regards,
Maciej


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120429/de73f480/attachment.html>