a search on 'deprecated' in contrib is pretty enlightening.
here's an example from spatial: DistanceApproximation entire class
deprecated!
* @deprecated This has been replaced with more accurate
* math in {...@link LLRect}.
this deprecation traces back to LUCENE-1781, which is marked as Fix
Version 2.9
makes me want to delete it, except if you check contrib/CHANGES, you
see it wasn't actually applied until 3.0
so it shouldnt be deleted yet.
again, not trying to be negative, +1 to both the contributor(s) and
committers that fixed this bug in spatial, as I sure don't
understand it.
On Fri, Oct 30, 2009 at 4:40 PM, Mark Miller <markrmil...@gmail.com>
wrote:
What deprecations were already added?
Robert Muir wrote:
> well, not to complain, but I will mention on this topic.
>
> If something is marked deprecated, its 10x easier if in the javadocs
> there is some version information applied.
>
> In the wild west that is contrib, its currently a bit difficult
for me
> to clear out the deprecations from 2.9, because there are new
> deprecations added in 3.0.
> it takes svn annotate + jira + CHANGES to figure out exactly what
> should be cleared out (and sometimes these all seem to disagree, Fix
> Version != Changes, etc etc)
>
> This is why i only did part of LUCENE-2022
>
> On Fri, Oct 30, 2009 at 4:16 PM, Mark Miller <markrmil...@gmail.com
> <mailto:markrmil...@gmail.com>> wrote:
>
> I have no problem with new features either - but I would vote
that
> if it
> requires new deprecations, it should wait.
>
> I think its nice to have a clean release first. And I also
don't think
> any of this features should hold up the 3.0 release. Lets get
it out -
> then focus on new features.
>
> Grant Ingersoll wrote:
> > How do you handle deprecations of old stuff for the new
contribution
> > (assuming it needs it)? Seems weird to have a major release
that
> > immediately has deprecations. At the same time, it seems
weird to
> > have a major release that doesn't contain new features. If
> anything,
> > it is our best opportunity to put in new stuff
> >
> > Traditionally, the only difference between .9 and .0 has been
> removal
> > of deprecations. This time around we are saying also JDK 1.5.
> >
> > Not saying we can't do it, just wondering.
> >
> > On Oct 30, 2009, at 3:31 PM, DM Smith wrote:
> >
> >> I don't see any reason to freeze new contributions from any
> release.
> >>
> >> On 10/30/2009 03:19 PM, Robert Muir wrote:
> >>> thanks Michael.
> >>>
> >>> does anyone else have any opinion on this issue?
> >>> fyi we already have several new features committed to 3.0
contrib
> >>> already (see contrib/CHANGES),
> >>> but I don't too much care either way, if I should not be
> adding this
> >>> feature to 3.0, I'd like to set the version in jira to 3.1
> >>>
> >>> On Fri, Oct 23, 2009 at 5:13 PM, Michael McCandless
> >>> <luc...@mikemccandless.com
<mailto:luc...@mikemccandless.com>
> <mailto:luc...@mikemccandless.com
> <mailto:luc...@mikemccandless.com>>> wrote:
> >>>
> >>> I think we should allow new features into contrib for
3.0.
> >>>
> >>> I don't even like holding new features from core for
3.0.
> >>>
> >>> In general I don't think it's healthy when trunk is
locked
> down....
> >>> Trunk should be like a locomotive that's plowing ahead
at
> all times.
> >>>
> >>> Mike
> >>>
> >>> On Thu, Oct 22, 2009 at 1:48 PM, Robert Muir
> <rcm...@gmail.com <mailto:rcm...@gmail.com>
> >>> <mailto:rcm...@gmail.com <mailto:rcm...@gmail.com>>>
wrote:
> >>> > Hi,
> >>> >
> >>> > What is the consensus on new features for contrib
for Lucene
> >>> 3.0? I know
> >>> > that for core, its mostly a java 5 upgrade and
deprecation
> >>> removal.
> >>> >
> >>> > I want to make sure LUCENE-1606 is set to the right
version,
> >>> but I figured
> >>> > its really not just about that specific issue, I would
> like to
> >>> know the
> >>> > plans in general.
> >>> >
> >>> > Thanks,
> >>> > Robert
> >>> >
> >>> > --
> >>> > Robert Muir
> >>> > rcm...@gmail.com <mailto:rcm...@gmail.com>
> <mailto:rcm...@gmail.com <mailto:rcm...@gmail.com>>
> >>> >
> >>>
> >>>
>
---------------------------------------------------------------------
> >>> To unsubscribe, e-mail:
> java-dev-unsubscr...@lucene.apache.org
> <mailto:java-dev-unsubscr...@lucene.apache.org>
> >>> <mailto:java-dev-unsubscr...@lucene.apache.org
> <mailto:java-dev-unsubscr...@lucene.apache.org>>
> >>> For additional commands, e-mail:
> java-dev-h...@lucene.apache.org
> <mailto:java-dev-h...@lucene.apache.org>
> >>> <mailto:java-dev-h...@lucene.apache.org
> <mailto:java-dev-h...@lucene.apache.org>>
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Robert Muir
> >>> rcm...@gmail.com <mailto:rcm...@gmail.com>
> <mailto:rcm...@gmail.com <mailto:rcm...@gmail.com>>
> >>
> >
> >
>
>
> --
> - Mark
>
> http://www.lucidimagination.com
>
>
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
> <mailto:java-dev-unsubscr...@lucene.apache.org>
> For additional commands, e-mail: java-dev-h...@lucene.apache.org
> <mailto:java-dev-h...@lucene.apache.org>
>
>
>
>
> --
> Robert Muir
> rcm...@gmail.com <mailto:rcm...@gmail.com>
--
- Mark
http://www.lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
--
Robert Muir
rcm...@gmail.com