definitely wasn't trying to single you out, again.
besides, this isn't the only instance. just the one that i could remember.
I'll set LUCENE-1606 to 3.1, even tho it doesn't deprecate anything, lets
focus on clearing this shit up and making a clean 3.0 release.
On Fri, Oct 30, 2009 at 5:30 PM, Michael McCandless <
luc...@mikemccandless.com> wrote:
> Mea culpa ;) (on LUCENE-1781)
>
> And I agree we need a better solution in general. I think not
> deprecating new stuff until the .0 release is out seems best? I think
> this .0 release is also especially challenging because we're (well,
> Uwe and a few others -- thanks)'re taking advantage of 1.5's new
> features. Hopefully, for 4.0, it'll be less work and faster
> turnaround.
>
> Mike
>
> On Fri, Oct 30, 2009 at 4:56 PM, Mark Miller <markrmil...@gmail.com>
> wrote:
> > Negative shcmegative :)
> >
> > Your right - this needs to be handled better. If we are going to add new
> > deprecations before all of the old deprecations are removed, there needs
> > to be help in the javadocs.
> >
> > Of course its nothing against those that did it - they likely didn't see
> > this issue - I don't think any of us ever care about blame or fault.
> > Just solutions ;) And this needs one.
> >
> > Robert Muir wrote:
> >> I don't want to come across as negative here... i'm not trying to
> >> single anyone out,
> >> just a bit confused as to why my issue was singled out when theres
> >> already been both new features and new deprecations added to 3.0,
> >> and the issue in question doesnt even have any deprecations. then
> >> again i don't really care if its in 3.0 or 3.1, but its just wierd.
> >>
> >> 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
> >> <mailto: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>
> >> > <mailto: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
> >>
> >> > <mailto: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>>
> >> > >>> <mailto: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>>
> >> > <mailto: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>>
> >> > >>> <mailto: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>>
> >> > >>> <mailto: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>>
> >> > <mailto: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>
> >> > <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
> >
> >
>
> ---------------------------------------------------------------------
> 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
