I was thinking about this, also precommit warnings, but never got ‘round to it.
I think deprecations hang around until they annoy someone enough to remove them. I agree it makes sense to remove usages when you deprecate a method, but it’s hit-or-miss, and often varies on how many files that touches. Some of the constructors used in Solr test cases are all over the test code for instance. I _would_ like people to be much more careful when deprecating methods about noting what release it was deprecated in. For back-compat we try to keep deprecated methods around for a while, and if I have some time to try remove usages @Deprecated is not nearly as useful as @Deprecated // TODO remove for 8.0 ‘cause I have to go figure out what version the first one was deprecated in before I dare remove it. As far as the JDK is concerned, when we stop developing branch_8x we can only remove deprecations from master…. Which I predict will lead to a shorter cycle between 8.0 and 9.0 than is usual for a major release ;) FWIW > On Jul 4, 2019, at 7:59 AM, Uwe Schindler <[email protected]> wrote: > > Hi, > > By default, we disable deprecation warnings in our build configurations, as > those are always confusing for library maintainers, as deprecated stuff often > has to be called from your own library code (depends on the way how you > preserve backwards compatibility). Or just because you need to test old > stuff). > > To prevent deprecated code from the JDK to be called, we use forbiddenapis > ("jdk-deprecated" signature). > > Uwe > > ----- > Uwe Schindler > Achterdiek 19, D-28357 Bremen > https://www.thetaphi.de > eMail: [email protected] > >> -----Original Message----- >> From: Michael Sokolov <[email protected]> >> Sent: Thursday, July 4, 2019 3:15 PM >> To: [email protected] >> Subject: Re: deprecations >> >> Ah yes, I am looking at branch_8x, duh. OK, the RAM-related >> deprecation warnings I was seeing do not show up on master. I guess >> the general question still stands though; for example when we >> deprecated RAMDirectory, did we at the same time remove all usages? >> That seems like "best practice," but e.g. we have not done that with >> these LegacyDocValues usages. Is it that it was just too burdensome >> there? It seems that at some point we will have to replace those >> usages with the newer DocValues APIs. >> >> On Thu, Jul 4, 2019 at 9:02 AM Dawid Weiss <[email protected]> >> wrote: >>> >>> >>> I think ram directory has been removed already on master? >>> >>> On Thu, Jul 4, 2019, 14:56 Michael Sokolov <[email protected]> wrote: >>>> >>>> I'm curious what the process for dealing with deprecations (and their >>>> annoying compiler warnings) has been in the past? I see we have a >>>> large number of these stemming from @Deprecation of >> RAMOutputStream, >>>> RAMInputStream, RAMDirectory, etc, as well as various legacy DocValues >>>> classes, and probably others. Do people usually wait until the >>>> deprecated classes are actually removed in order to clean up their >>>> usage (ie next major release)? It would make sense to me to try to get >>>> ahead of that and clean up the usages earlier, probably in a commit >>>> per deprecated class (or set of related classes). Do we have issues >>>> for this work? It might be something we could inspire aspiring >>>> committers to take on as it can be clearly defined, but is also large >>>> in scope. >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
