In ordinary cases where there is no API change, I don't think the problem is so severe. But removing APIs, even deprecated ones, is always hard, just look at the Web and the debates over vendor prefixes. At Google we do have tools that help with 'company wide refactoring', the EventListener issue I think is a special case, because there are some apps like AdWords, that have been written in GWT since early versions, and which are in the millions of lines of code. New code is written using the *Handlers, but there's still tons of stuff where deprecated APIs are in use and no one has put into the effort to port them all over. I don't think new users are using *Listener, it's just a matter of getting legacy code ported.
On Tue, Sep 4, 2012 at 3:48 PM, Stephen Haberman <step...@exigencecorp.com> wrote: > >> give internal teams a lead time to fix their usages first > > Haven't these been deprecated since ~2008? How much more lead time is > necessary? Is there a "@NoSeriouslyWeReallyMeanItDeprecated" annotation > we should use instead? > > Even with the new process, if google-vendor is going to diverge from > trunk everytime more than a handful of the internal Google projects > that were written in (and probably not touched since) 2008 fail to > compile, it seems like we'll quickly have a non-trivial divergence that > will be a pita. I would look forward to being proven wrong through. > > Also, I realize this is probably reality for now, but hopefully it is > just a short term growing pain. > > - Stephen > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
