That makes sense. Your idea about commenting the deprecation version,
especially. I guess I was imagining we might have a convention like
always deprecating on the current release branch + master - then it
would always be safe to remove on master, but that might not be
workable in every case, and an explicit comment would really help.
On Thu, Jul 4, 2019 at 11:56 AM Erick Erickson <erickerick...@gmail.com> wrote:
>
> 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 <u...@thetaphi.de> 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: u...@thetaphi.de
> >
> >> -----Original Message-----
> >> From: Michael Sokolov <msoko...@gmail.com>
> >> Sent: Thursday, July 4, 2019 3:15 PM
> >> To: dev@lucene.apache.org
> >> 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 <dawid.we...@gmail.com>
> >> wrote:
> >>>
> >>>
> >>> I think ram directory has been removed already on master?
> >>>
> >>> On Thu, Jul 4, 2019, 14:56 Michael Sokolov <msoko...@gmail.com> 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: dev-unsubscr...@lucene.apache.org
> >>>> For additional commands, e-mail: dev-h...@lucene.apache.org
> >>>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >> For additional commands, e-mail: dev-h...@lucene.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
