I agree, we have announed the 2.9/3.0 release plans a long time ago
already and shouldn't change anything. But ideally I'd like to announce
any backwards-compatibility changes together with the 3.0 release, while
mentioning that the changes will take effect from 3.1 on. That's why I'd
like to get to a conclusion soon.
Michael
On 10/3/09 12:18 PM, Uwe Schindler wrote:
But we should not change for 3.0, because people have already much to do to
get their 2.9 compile without deprec. If the work is then obsolete, because
we change this fundamental, we will make a lot of people angry. So I would
do this for 3.1.
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
-----Original Message-----
From: Michael Busch [mailto:busch...@gmail.com]
Sent: Saturday, October 03, 2009 12:15 PM
To: java-dev@lucene.apache.org
Subject: Re: Lucene 2.9 and deprecated IR.open() methods
There's also LUCENE-1698! Maybe we can change the policy. Now that 2.9
is out we should try to get to a conclusion.
Michael
On 10/3/09 11:54 AM, Michael McCandless wrote:
Well, let's first get 3.0 out the door ;) Then we can salivate over
all sorts of juicy changes for 3.1...
These particular changes (switching syntax from multi-ctors to config
or to builder, disallowing config changes after creation, switching to
"concrete impl is hidden") may merit an exception to our back-compat
policy. Obviously users are bothered by the horror of how many ctors
you are confronted with for IW and IR.
Mike
On Sat, Oct 3, 2009 at 5:46 AM, Uwe Schindler<u...@thetaphi.de> wrote:
Hi,
The problem is, we have to leave some of the not-yet-deprecated
ctors/opens
available for a while (not until 4.0 with our ne policy), but a user
removing all deprecated stuff from his 2.9 release should be able to
switch
to 3.0 without changing any code (can even plug the jars in). We also
have
to keep the getters/setter avail. If we wanted to change this, 2.9 was
the
best option :-(
Uwe
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
-----Original Message-----
From: Michael McCandless [mailto:luc...@mikemccandless.com]
Sent: Saturday, October 03, 2009 11:35 AM
To: java-dev@lucene.apache.org
Subject: Re: Lucene 2.9 and deprecated IR.open() methods
On Fri, Oct 2, 2009 at 10:18 PM, Earwin Burrfoot<ear...@gmail.com>
wrote:
Call me old fashioned, but I like how the non constructor params are
set
now.
And what happens when you index some docs, change these params, index
more docs, change params, commit? Let's throw in some threads?
You either end up writing really hairy state control code, or just
leave it broken, with "Don't change parameters after you start
pumping
docs through it!" plea covering your back somewhere in JavaDocs.
If nothing else, having stuff 'final' keeps JIT really happy.
This is a good point: are you allowed to change config settings after
creating your IndexWriter/Reader?
Today it's ad hoc.
EG IW does not allow you to swap out your deletion policy, because
it'd be a nightmare to implement. You also can't swap the analyzer.
But it does let you change your RAM buffer size, CFS or not, merge
factor, etc. We can remove that flexibility (I'm not sure it's
compelling), so we can make things final. You can't change read-only
after opening your IndexReader. I think it'd make sense to move away
from changing settings after construction...
But: the "do we disallow changing config settings after construction?"
question is really orthogonal to the "what syntax do we use for
construction?" (builder vs config vs zillions-of-ctors).
Mike
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
