+1 for fixing deprecation warnings when bumping/changing dependencies. Not only for the dependencies, we also use the deprecated API of Flink itself in `flink-examples` and the document, e.g. the #writeAsText. I think it would be good to do a clean-up for usability. WDYT?
Best, Yangze Guo On Wed, Jul 14, 2021 at 3:57 PM Till Rohrmann <trohrm...@apache.org> wrote: > > I think this suggestion makes a lot of sense, Stephan. +1 for fixing > deprecation warnings when bumping/changing dependencies. I actually found > myself recently, whenever touching a test class, replacing Junit's > assertThat with Hamcrest's version which felt quite tedious. > > Cheers, > Till > > On Tue, Jul 13, 2021 at 6:15 PM Stephan Ewen <se...@apache.org> wrote: > > > Hi all! > > > > I would like to propose that we make it a project standard that when > > upgrading a dependency, deprecation issues arising from that need to be > > fixed in the same step. If the new dependency version deprecates a method > > in favor of another method, all usages in the code need to be replaced > > together with the upgrade. > > > > We are accumulating deprecated API uses over time, and it floods logs and > > IDEs with deprecation warnings. I find this is a problem, because the > > irrelevant warnings more and more drown out the actually relevant warnings. > > And arguably, the deprecation warning isn't fully irrelevant, it can cause > > problems in the future when the method is actually removed. > > We need the general principle that a change leaves the codebase in at least > > as good shape as before, otherwise things accumulate over time and the > > overall quality goes down. > > > > The concrete example that motivated this for me is the JUnit dependency > > upgrade. Pretty much every test I looked at recently is quite yellow (due > > to junit Matchers.assertThat being deprecated in the new JUnit version). > > This is easily fixed (even a string replace and spotless:apply goes a long > > way), so I would suggest we try and do these things in one step in the > > future. > > > > Curious what other committers think about this suggestion. > > > > Best, > > Stephan > >
