@Chesnay - Good question. I think we can be pragmatic there. If you upgrade Jackson, pick a class that uses it and look for the common methods. If everything is fine there, it is probably fine overall. If one or two deprecated method usages are overlooked, no problem, that's not an issue. If a common method gets deprecated, then chance is high you spot it quickly when looking at some Jackson usages.
@Yangze - Agreed, we should do the same internally and make sure we keep our own API use and examples up to date. On Wed, Jul 14, 2021 at 11:00 AM Chesnay Schepler <ches...@apache.org> wrote: > How do you propose to do this in practice? > Let's say I bump jackson, how would I find all new usages of deprecated > APIs? > Build it locally and grep the maven output for jackson? > > On 14/07/2021 10:51, Yangze Guo wrote: > > +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 > >>> > >
