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

Reply via email to