[webkit-dev] Deprecating JS interface

[Maciej Stachowiak]

On Feb 17, 2013, at 1:09 AM, Filip Pizlo <fpizlo at apple.com> wrote:

> 
> On Feb 17, 2013, at 1:04 AM, Dirk Schulze <dschulze at adobe.com> wrote:
> 
>> 
>> The discussion on each single feature let us forget the greater scope of this problem. That is why I did not start with a concrete example.
>> 
>> What about going another direction? Right now we have compiler flags for a lot of new features. What if we turn this around? Why not having a compiler flag ENABLE_DEPRECATED_FEATURES? This must be turned on in trunk to make sure deprecated features still work properly. Release builds should turn it on to not break compatibility. But every binary build of a nightly or preview has it turned off. A lot of developers experiment with Chrome Canary and WebKit nightlies already. It might be a drop in the bucket, but still can have some influence on decreasing the use of deprecated content. Features like CSS gradients, transitions and animations might be good candidates at the beginning for this flag.
> 
> This carries the risk of decreasing test coverage of Nightlies and Canaries.  I don't think that is acceptable.
> 
> Users who download them and cannot use a web page because that page had deprecated features will then not be able to experience what bugs we had, those deprecated features notwithstanding.
> 
> I empathize with the desire to remove cruft.  But we shouldn't remove things if it breaks the web, even in Nightlies and Canaries.

I agree with Phil. And as a corollary, if removing something *doesn't* break the Web and we think it's otherwise bad, then there's no need to do a special dance with nightlies before removing.

Cheers,
Maciej