You can give it a shot, but we will have to revert it for a project as soon as a project uses a deprecated API somewhere.
On Fri, Jul 24, 2015 at 7:43 AM, Punyashloka Biswal <punya.bis...@gmail.com> wrote: > Would it make sense to isolate the use of deprecated warnings to a subset > of projects? That way we could turn on more stringent checks for the other > ones. > > Punya > > On Thu, Jul 23, 2015 at 12:08 AM Reynold Xin <r...@databricks.com> wrote: > >> Hi all, >> >> FYI, we just merged a patch that fails a build if there is a scala >> compiler warning (if it is not deprecation warning). >> >> In the past, many compiler warnings are actually caused by legitimate >> bugs that we need to address. However, if we don't fail the build with >> warnings, people don't pay attention at all to the warnings (it is also >> tough to pay attention since there are a lot of deprecated warnings due to >> unit tests testing deprecated APIs and reliance on Hadoop on deprecated >> APIs). >> >> Note that ideally we should be able to mark deprecation warnings as >> errors as well. However, due to the lack of ability to suppress individual >> warning messages in the Scala compiler, we cannot do that (since we do need >> to access deprecated APIs in Hadoop). >> >> >>
