Criteria for deprecation vs. removal

Philip Jägenstedt

unread,

Mar 10, 2014, 4:08:33 AM3/10/14

to blink-dev

Hi Blinkers!

Currently, things are only deprecated when we're almost certain that it can be removed soon, i.e. when the use counters are below ~0.03%. Deprecating for a release cycle is a great way to give (active) developers a heads-up. We don't want to deprecate everything, because then the warnings will become too many to be taken seriously.

However, I think that we could get more out of the deprecation step if we had a slightly higher threshold for deprecation. In <http://www.chromestatus.com/metrics/feature/popularity>, there are plenty of bad features we would like to remove that are above 0.03% but below 1%. Deprecating some of those could, in the best of worlds, help drive usage down over time to the point where they can be removed.

What do people think of this approach, raising the limit for deprecation to something like 1%, but of course still using the existing Intent to Deprecate process and applying good judgement?

Philip

Yoav Weiss

unread,

Mar 10, 2014, 6:17:38 AM3/10/14

to Philip Jägenstedt, blink-dev

Sounds like a good idea, assuming that it won't create too much console cruft for developers that they'd end up ignoring these warnings altogether.

Also - do we have any data indicating that deprecation warnings lead to reduced usage over time? (and possibly, at what rate the usage is reduced)

Adam Barth

unread,

Mar 10, 2014, 11:43:52 AM3/10/14

to phi...@opera.com, blin...@chromium.org

On Mon Mar 10 2014 at 1:08:37 AM, Philip Jägenstedt <phi...@opera.com> wrote:

Currently, things are only deprecated when we're almost certain that it can be removed soon, i.e. when the use counters are below ~0.03%. Deprecating for a release cycle is a great way to give (active) developers a heads-up. We don't want to deprecate everything, because then the warnings will become too many to be taken seriously.

We might want to check the set of features that are currently deprecated to make sure we're serious about removing them. If we print deprecation messages for a popular feature and then don't remove it, we're teaching developers to ignore deprecation messages.

However, I think that we could get more out of the deprecation step if we had a slightly higher threshold for deprecation. In <http://www.chromestatus.com/metrics/feature/popularity>, there are plenty of bad features we would like to remove that are above 0.03% but below 1%. Deprecating some of those could, in the best of worlds, help drive usage down over time to the point where they can be removed.

What do people think of this approach, raising the limit for deprecation to something like 1%, but of course still using the existing Intent to Deprecate process and applying good judgement?

IMHO, we should only deprecate features that we have a realistic chance of actually removing. Maybe we should try one of these 1% features as an example? My fear is that we won't be able to remove features with usage that high and we'll be spamming deprecation messages.

Adam

Ian Hickson

unread,

Mar 10, 2014, 2:37:52 PM3/10/14

to Philip Jägenstedt, blink-dev

On Mon, 10 Mar 2014, Philip Jägenstedt wrote:
>
> What do people think of this approach, raising the limit for deprecation
> to something like 1%, but of course still using the existing Intent to
> Deprecate process and applying good judgement?

1% is an absurdly high level of usage. Assuming "InputTypePassword" is
simply <input type=password>, consider that that is only at about 4%.

There are features that I think are critical to the health of the platform
that I would not be surprised never to see receive even 1% usage.

--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'

Glenn Adams

unread,

Mar 10, 2014, 3:36:35 PM3/10/14

to Ian Hickson, Philip Jägenstedt, blink-dev

On Mon, Mar 10, 2014 at 12:37 PM, Ian Hickson <i...@hixie.ch> wrote:

On Mon, 10 Mar 2014, Philip Jägenstedt wrote:
>
> What do people think of this approach, raising the limit for deprecation
> to something like 1%, but of course still using the existing Intent to
> Deprecate process and applying good judgement?

1% is an absurdly high level of usage. Assuming "InputTypePassword" is
simply <input type=password>, consider that that is only at about 4%.

There are features that I think are critical to the health of the platform
that I would not be surprised never to see receive even 1% usage.

I wholly agree with Ian. I've been quite uncomfortable to see the recent spate of deprecations based on what is effectively an arbitrary usage number. I am particularly unhappy to see overly zealous deprecation of features before sufficient time has been given to determine their usability or impact.

We need a better way to evaluate the cost of a feature versus its usage. For example, a feature that has a high implementation cost -- static/dynamic memory, lines of code, complexity, etc -- should be given more scrutiny than a low cost feature all else (usage % wise) being equal. We also need a better way of evaluating low usage features, e.g., is there more than one way to do the same thing without extraordinary effort/cost.

G.

Ian Hickson

unread,

Mar 10, 2014, 4:17:14 PM3/10/14

to Glenn Adams, Philip Jägenstedt, blink-dev

On Mon, 10 Mar 2014, Glenn Adams wrote:
>
> I've been quite uncomfortable to see the recent spate of deprecations
> based on what is effectively an arbitrary usage number. I am
> particularly unhappy to see overly zealous deprecation of features
> before sufficient time has been given to determine their usability or
> impact.

Just to clarify, I'm not saying that too much has been deprecated, nor
that the current bar (combined with the current multiple review) is wrong.
I was just pointing out that 1% was a big number at Web scale, even though
it may sound small.

Philip Jägenstedt

unread,

Mar 11, 2014, 12:18:38 AM3/11/14

to Adam Barth, blink-dev

On Mon, Mar 10, 2014 at 10:43 PM, Adam Barth <aba...@google.com> wrote:
> On Mon Mar 10 2014 at 1:08:37 AM, Philip Jägenstedt <phi...@opera.com>
> wrote:
>>
>> Currently, things are only deprecated when we're almost certain that it
>> can be removed soon, i.e. when the use counters are below ~0.03%.
>> Deprecating for a release cycle is a great way to give (active) developers a
>> heads-up. We don't want to deprecate everything, because then the warnings
>> will become too many to be taken seriously.
>
>
> We might want to check the set of features that are currently deprecated to
> make sure we're serious about removing them. If we print deprecation
> messages for a popular feature and then don't remove it, we're teaching
> developers to ignore deprecation messages.

>> However, I think that we could get more out of the deprecation step if we
>> had a slightly higher threshold for deprecation. In
>> <http://www.chromestatus.com/metrics/feature/popularity>, there are plenty
>> of bad features we would like to remove that are above 0.03% but below 1%.
>> Deprecating some of those could, in the best of worlds, help drive usage
>> down over time to the point where they can be removed.
>>
>> What do people think of this approach, raising the limit for deprecation
>> to something like 1%, but of course still using the existing Intent to
>> Deprecate process and applying good judgement?
>
>
> IMHO, we should only deprecate features that we have a realistic chance of
> actually removing. Maybe we should try one of these 1% features as an
> example? My fear is that we won't be able to remove features with usage
> that high and we'll be spamming deprecation messages.

Your fear turns out to be reality.

I suppose there are two ways of using at these deprecation messages:

1. A friendly warning to developers that their code will break soon if
they do not act.

2. A complaint to the developer that their code is contributing to
browser engine lock-in.

I think (1) is the currently intended usage, and then it doesn't make
sense to deprecate things with 1% usage.

I'm asking if we can't do a little bit of (2) as well, but not so much
that people ignore the messages. I think a good example is
webkitRequestAnimationFrame, currently at ~0.3%. When people fail to
use the requestAnimationFrame variant when available, that's bad for
the Web platform even if it doesn't hurt us. Any reduction would be a
win, even if it doesn't fall below 0.03% any time soon.

1% is just a random number, the point is that for (2) the number
doesn't need to be the same as for (1).

Philip

Adam Barth

unread,

Mar 11, 2014, 2:48:59 AM3/11/14

to phi...@opera.com, blin...@chromium.org

Maybe we should take that as an aspiration? :)

Complaining about Event.returnValue (24%) and Attr.specified (7%) is
not a good idea even if they're non-standard. Review to undeprecate:
https://codereview.chromium.org/194173002

Thanks for posting this CL!

We can use different message to distinguish between (1) and (2). For webkitRequestAnimationFrame, I agree that we should tell developers that they should use requestAnimationFrame instead. If we were really on top of things, we could even link to the data showing the current usage.

1% is just a random number, the point is that for (2) the number
doesn't need to be the same as for (1).

Yeah, that makes sense to me. We should just be mindful when we spend developer attention.

Thanks again for helping clean up the spammy messages. If you remove a 24% spammer, you'll certainly earned enough credibility to add a couple 1% messages. :)

Adam

Philip Jägenstedt

unread,

Mar 11, 2014, 3:29:43 AM3/11/14

to Adam Barth, blink-dev

On Tue, Mar 11, 2014 at 1:48 PM, Adam Barth <aba...@google.com> wrote:
> On Mon Mar 10 2014 at 9:18:38 PM, Philip Jägenstedt <phi...@opera.com>
> wrote:
>>
>> So much for "things are only deprecated when we're almost certain that
>> it can be removed soon"...
>
> Maybe we should take that as an aspiration? :)

Yeah. Some of the deprecations predate the current process, so it's
not surprising that it wasn't perfectly consistent.

>> I suppose there are two ways of using at these deprecation messages:
>>
>> 1. A friendly warning to developers that their code will break soon if
>> they do not act.
>>
>> 2. A complaint to the developer that their code is contributing to
>> browser engine lock-in.
>>
>> I think (1) is the currently intended usage, and then it doesn't make
>> sense to deprecate things with 1% usage.
>>
>> I'm asking if we can't do a little bit of (2) as well, but not so much
>> that people ignore the messages. I think a good example is
>> webkitRequestAnimationFrame, currently at ~0.3%. When people fail to
>> use the requestAnimationFrame variant when available, that's bad for
>> the Web platform even if it doesn't hurt us. Any reduction would be a
>> win, even if it doesn't fall below 0.03% any time soon.
>
> We can use different message to distinguish between (1) and (2). For
> webkitRequestAnimationFrame, I agree that we should tell developers that
> they should use requestAnimationFrame instead. If we were really on top of
> things, we could even link to the data showing the current usage.

I think that's a good idea. How about "'webkitRequestAnimationFrame'
is proprietary. Please use 'requestAnimationFrame' instead."? Too
scary?

>> 1% is just a random number, the point is that for (2) the number
>> doesn't need to be the same as for (1).
>
> Yeah, that makes sense to me. We should just be mindful when we spend
> developer attention.
>
> Thanks again for helping clean up the spammy messages. If you remove a 24%
> spammer, you'll certainly earned enough credibility to add a couple 1%
> messages. :)

Maybe a sensible next step is Intent to Deprecate threads for specific
low-use features that are not yet removable. If it works out, we'll
probably arrive at a reasonable threshold over time.

Philip

Adam Barth

unread,

Mar 11, 2014, 3:40:18 AM3/11/14

to phi...@opera.com, blin...@chromium.org

I'm not sure the word "proprietary" is quite right. It means "of or relating to an owner or ownership." I'm not sure anyone particularly owns webkitRequestAnimationFrame...

Maybe something like:

"Please consider using the standard 'requestAnimationFrame' function rather than the vendor-specific 'webkitRequestAnimationFrame' function."

?

>> 1% is just a random number, the point is that for (2) the number
>> doesn't need to be the same as for (1).
>
> Yeah, that makes sense to me. We should just be mindful when we spend
> developer attention.
>
> Thanks again for helping clean up the spammy messages. If you remove a 24%
> spammer, you'll certainly earned enough credibility to add a couple 1%
> messages. :)

Maybe a sensible next step is Intent to Deprecate threads for specific
low-use features that are not yet removable. If it works out, we'll
probably arrive at a reasonable threshold over time.