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]
