Yeah I tried to zap lots of those before the release, but there are still many of them, mostly from the accumulator change (really, that should have been fixed as part of the original change? not so nice to merge a change that adds 200 build warnings). Some deprecated code must be called from tests to still test the deprecated code but it ought to be possible to make the non-test code avoid it entirely.
On Wed, Jul 27, 2016 at 12:11 PM, Holden Karau <hol...@pigscanfly.ca> wrote: > Now that the 2.0 release is out the door and I've got some cycles to do some > cleanups - I'd like to know what other people think of the internal > deprecation warnings we've introduced in a lot of a places in our code. Once > before I did some minor refactoring so the Python code which had to use the > deprecated code to expose the deprecated API wouldn't gum up the build logs > - but is there interest in doing that or are we more interested in not > paying attention to the deprecation warnings for internal Spark components > (e.g. https://twitter.com/thepracticaldev/status/725769766603001856 )? > > > -- > Cell : 425-233-8271 > Twitter: https://twitter.com/holdenkarau --------------------------------------------------------------------- To unsubscribe e-mail: dev-unsubscr...@spark.apache.org
