On Feb 17, 2013, at 1:09 AM, Filip Pizlo <fpi...@apple.com> wrote: > > On Feb 17, 2013, at 1:04 AM, Dirk Schulze <dschu...@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 _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
