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 >
