Re: Lucene's default settings & back compatibility

Right - I'd actually hold off now. I figured the threat of sending might prompt some action ;) It still wouldn't hurt to know what the users think, perhaps at more digestible, overview level though. I do think Yonik torpedoed something this liberal :) Thats not a bad thing though. We will fi

Re: Lucene's default settings & back compatibility

Well .. to be honest I haven't monitored java-user for quite some time, so I don't know if it hasn't been raised there. But now there's the other thread that Yonik started, so I'm not really sure where to answer. I think that if we look back at 2.0 and compare to 2.9, anyone upgrading from that v

Re: Lucene's default settings & back compatibility

No one really responded to this Shai? And I take it that the user list never saw it? Perhaps we should just ask for opinion from the user list based on what you already have - just to gauge the reaction on different points. Unless someone responds shortly, we could take a year waiting to shake

Re: Lucene's default settings & back compatibility

Ok, so digging back in this thread, I think the following proposals were made (if I missed some, please add them): 1. API deprecation last *at least* one full minor release. Example: if we deprecate an API in 2.4, we can remove it in 2.5. BUT, we are also free to keep it there and remove it in 2.6

Re: Lucene's default settings & back compatibility

I think one conclusion that did come of this discussion was that bugs should be fixed even if it breaks backward compatibility. -- DM On May 30, 2009, at 7:21 AM, Michael McCandless wrote: Actually, I think this is a common, and in fact natural/expected occurrence in open-source. When a tri

Re: Lucene's default settings & back compatibility

Actually, I think this is a common, and in fact natural/expected occurrence in open-source. When a tricky topic is discussed, and the opinions are often divergent, frequently the conversation never "converges" to a consensus and the discussion dies. Only if discussion reaches a semblance of conse

Re: Lucene's default settings & back compatibility

I think the last piece that is needed is to ask on java-user what others think. In order to do that, I think it needs to be boiled down to a couple paragraphs. -Grant On May 29, 2009, at 11:22 PM, Shai Erera wrote: So ... I've this happen a lot of times (especially in my thesis work) - s

Re: Lucene's default settings & back compatibility

As far as I understand the policy-making process, someone from PMC has to start the vote, and then PMC members should, well, vote. Without them taking action we can "beep" to our hearts' content without any consequences. On Sat, May 30, 2009 at 07:22, Shai Erera wrote: > So ... I've this happen a

Re: Lucene's default settings & back compatibility

So ... I've this happen a lot of times (especially in my thesis work) - someone raises a controversial topic, or one that touches the nervous of the system, there's a flurry of activity and then it dies unexpectedly, even though it feels to everyone that there's "an extra mile" that should be taken

Re: Lucene's default settings & back compatibility

So, here's a real, concrete example of the need for case by case back compat. See https://issues.apache.org/jira/browse/LUCENE-1662 It's completely stupid that ExtendedFieldCache even exists. It is a dumb workaround for a made up problem that has nothing to do with real coders living in

Re: Lucene's default settings & back compatibility

OK thanks Shai! Mike On Mon, May 25, 2009 at 12:18 AM, Shai Erera wrote: > Yes - 1630. > > I'll check 1601 and if nothing's left to do I'll cancel/close it > > On Sun, May 24, 2009 at 11:25 PM, Michael McCandless > wrote: >> >> Actually, under LUCENE-1601, what more was there to do besides turn

Re: Lucene's default settings & back compatibility

Yes - 1630. I'll check 1601 and if nothing's left to do I'll cancel/close it On Sun, May 24, 2009 at 11:25 PM, Michael McCandless < luc...@mikemccandless.com> wrote: > Actually, under LUCENE-1601, what more was there to do besides turning > off scoring when sorting by field, by default? > > Is t

Re: Lucene's default settings & back compatibility

Actually, under LUCENE-1601, what more was there to do besides turning off scoring when sorting by field, by default? Is there an issue for adding & mating Scorer.scoresDocsInOrder & Collector.acceptsDocsOutOfOrder? Mike On Sun, May 24, 2009 at 3:22 PM, Shai Erera wrote: > I created LUCENE-1601

Re: Lucene's default settings & back compatibility

I created LUCENE-1601 for that purpose with a fix-version 3.0. I noticed you already opened another issue for the scoring only. So we should remove it from there (note that there's a TODO in the code, if you plan to change it in the new issue you opened). 1601 will still handle the new method added

Re: Lucene's default settings & back compatibility

I'll open an issue for this and we can discuss under there. And I still need to open issues for the other "change defaluts" in my original email. Mike On Sun, May 24, 2009 at 8:11 AM, Shai Erera wrote: >> I'm tempted to simply make that change by default for 2.9, now. > > Agree ! > > Shai > > O

Re: Lucene's default settings & back compatibility

> > I'm tempted to simply make that change by default for 2.9, now. > Agree ! Shai On Sun, May 24, 2009 at 1:28 PM, Michael McCandless < luc...@mikemccandless.com> wrote: > On Sun, May 24, 2009 at 2:20 AM, Shai Erera wrote: > > One thing I don't fully understand about actsAsVersion (and I know

Re: Lucene's default settings & back compatibility

On Sun, May 24, 2009 at 2:20 AM, Shai Erera wrote: > One thing I don't fully understand about actsAsVersion (and I know it was > said that we may want to drop that approach) - for how long does it stay? I > mean, let's take the invalidAcronym. It is a change in back-compat, yes. But > for how long

Re: Lucene's default settings & back compatibility

One thing I don't fully understand about actsAsVersion (and I know it was said that we may want to drop that approach) - for how long does it stay? I mean, let's take the invalidAcronym. It is a change in back-compat, yes. But for how long are we expected to support it? And if we decide to support

Re: Lucene's default settings & back compatibility

On Fri, May 22, 2009 at 3:37 PM, DM Smith wrote: > So, what is it that they use that leads to such unfavorable results? I think it's simply that they take each search engine, get it to index their collection in the most obvious way, perhaps having read a tutorial somewhere, and test that. I'm g

Re: Lucene's default settings & back compatibility

Earwin Burrfoot wrote: 4. [Maybe?] Allow certain limited changes that will require source code changes in your app on upgrading to a new minor release: adding a new method to an interface, adding a new abstract method to an abstract class, renaming of deprecated methods. Yaho

Re: Lucene's default settings & back compatibility

On Fri, May 22, 2009 at 10:40:03PM +0400, Earwin Burrfoot wrote: > >> Custom analyzers. > > No problem. > How are they recorded in the index? Analyzers must implement dump() and load(), which convert the Analyzer to/from a JSON-izable data structure. They end up as JSON in index_dir/schema_NNN.js

Re: Lucene's default settings & back compatibility

Michael McCandless wrote: Well... I would expect & hope Lucene's adoption is growing with time, so the number of new users should increase on each release. For a healthy project that's relatively young compared to its potential user base, that growth should be exponential. And, I'd expect the v

Re: Lucene's default settings & back compatibility

Well... I would expect & hope Lucene's adoption is growing with time, so the number of new users should increase on each release. For a healthy project that's relatively young compared to its potential user base, that growth should be exponential. And, I'd expect the vast majority of old users do

Re: Lucene's default settings & back compatibility

I'd like to do this for 2.9 :) I'll open an issue... (Yes this would just be for diagnostics). Mike On Fri, May 22, 2009 at 1:48 PM, DM Smith wrote: > Yonik Seeley wrote: >> >> On Fri, May 22, 2009 at 1:22 PM, Michael McCandless >> wrote: >> >>> >>> (That said, unrelated to this discussion, I

Re: Lucene's default settings & back compatibility

Michael McCandless wrote: On Fri, May 22, 2009 at 2:27 PM, DM Smith wrote: Marvin Humphrey wrote: I feel the opposite: I'd like new users to see improvements by default, and users that require strict back-compate to ask for that. By "strict back-compat", do you mean "people

Re: Lucene's default settings & back compatibility

OK, net/net it doesn't look like we're going reach agreement on some general approach for having users of Lucene always get the best default settings. We started with the *Settings classes, but that's really a very large project (goes far beyond managing defaults for new users). Then we went to t

Re: Lucene's default settings & back compatibility

>> Custom analyzers. > No problem. How are they recorded in the index? >> Several indexes using the same analyzer. > No problem.  Only necessary if the analyzer is costly or has some esoteric > need for shared state.  And possible via subclassing Schema or Analyzer. It is. >> Intentionally differ

Re: Lucene's default settings & back compatibility

On Fri, May 22, 2009 at 2:27 PM, DM Smith wrote: > Marvin Humphrey wrote: >>> >>> I feel the opposite: I'd like new users to see improvements by >>> default, and users that require strict back-compate to ask for that. >>> >> >> By "strict back-compat", do you mean "people who would like their sear

Re: Lucene's default settings & back compatibility

Marvin Humphrey wrote: I feel the opposite: I'd like new users to see improvements by default, and users that require strict back-compate to ask for that. By "strict back-compat", do you mean "people who would like their search app to not fail silently"? ;) A "new user" who follows your a

Re: Lucene's default settings & back compatibility

On Fri, May 22, 2009 at 09:06:32PM +0400, Earwin Burrfoot wrote: > > In KinoSearch SVN trunk, satellite classes like QueryParser and Highlighter > > have to be passed a Schema, which contains all the Analyzers.  Analyzers > > aren't satellite classes under this model -- they are a fixed property of

Re: Lucene's default settings & back compatibility

Michael McCandless wrote: On Fri, May 22, 2009 at 12:52 PM, Marvin Humphrey wrote: when working on 3.1 if we make some great improvement, I'd like new users in 3.1 to see the improvement by default. Sounds like an argument for more frequent major releases. Yeah. Or "rebrandin

Re: Lucene's default settings & back compatibility

On Fri, May 22, 2009 at 01:22:24PM -0400, Michael McCandless wrote: > > Sounds like an argument for more frequent major releases. > > Yeah. Or "rebranding" what we now call minor as major releases, by > changing our policy ;) Not sure how much of that is a jest, bug I don't think that's a good

Re: Lucene's default settings & back compatibility

tially relaxing back compat requirements is > enough of a change that it should at some point go to a vote (once > people figure out exactly what is being voted on ;-) Definitely, if we can actually figure out what to vote on, we should vote on this change... > That doesn't appl

Re: Lucene's default settings & back compatibility

> I feel the opposite: I'd like new users to see improvements by > default, and users that require strict back-compate to ask for that. By "strict back-compat", do you mean "people who would like their search app to not fail silently"? ;) A "new user" who follows your advice... // haha stupid

Re: Lucene's default settings & back compatibility

Yonik Seeley wrote: On Fri, May 22, 2009 at 1:22 PM, Michael McCandless wrote: (That said, unrelated to this discussion, I would actually like to record per-segment which version of Lucene wrote the segment; this would be very helpful when debugging issues like LUCENE-1474 where I need to kn

Re: Lucene's default settings & back compatibility

On Fri, May 22, 2009 at 12:37 PM, Marvin Humphrey wrote: > I still like per-class settings classes. For instance, an IndexWriterSettings > class which allows you to hide away all the tweaky stuff that's cluttering up > the IndexWriter API. > > IndexWriterSettings settings = new IndexWriterSett

Re: Lucene's default settings & back compatibility

On Fri, May 22, 2009 at 1:22 PM, Michael McCandless wrote: > (That said, unrelated to this discussion, I would actually like to > record per-segment which version of Lucene wrote the segment; this > would be very helpful when debugging issues like LUCENE-1474 where I > need to know if the segments

Re: Lucene's default settings & back compatibility

On Fri, May 22, 2009 at 12:52 PM, Marvin Humphrey wrote: > >> when working on 3.1 if we make some great improvement, I'd like new users in >> 3.1 to see the improvement by default. > > Sounds like an argument for more frequent major releases. Yeah. Or "rebranding" what we now call minor as major

Re: Lucene's default settings & back compatibility

> In KinoSearch SVN trunk, satellite classes like QueryParser and Highlighter > have to be passed a Schema, which contains all the Analyzers.  Analyzers > aren't satellite classes under this model -- they are a fixed property of a > FullTextType field spec.  Think of them as baked into an SQL field

Re: Lucene's default settings & back compatibility

On Fri, May 22, 2009 at 11:33:33AM -0400, Michael McCandless wrote: > when working on 3.1 if we make some great improvement, I'd like new users in > 3.1 to see the improvement by default. Sounds like an argument for more frequent major releases. But I'm not exactly one to talk. ;) > On think

Re: Lucene's default settings & back compatibility

(once people figure out exactly what is being voted on ;-) That doesn't apply to a static actsAsVersion that would preserve back compatibility by default of course. >  3. Default settings can change, but if the change is big enough (and >     certainly if it will impact what's ind

Re: Lucene's default settings & back compatibility

On Fri, May 22, 2009 at 11:53:02AM -0400, Michael McCandless wrote: > 1. If we deprecate an API in the 2.1 release, we can remove it in > the next minor release (2.2). > > 2. JAR drop-in-ability is only guaranteed on point releases (2.4.1 > is a drop-in replacement to 2.4.0). When

Re: Lucene's default settings & back compatibility

>  1. If we deprecate an API in the 2.1 release, we can remove it in >     the next minor release (2.2). Agree. Maybe also this? 1a. If deprecated functionality is trivially implemented with new one, we reserve the right to delete deprecated things right away with appropriate CHANGES note. Sample I

Re: Lucene's default settings & back compatibility

So, iterating on the proposed changes to back-compat policy: 1. If we deprecate an API in the 2.1 release, we can remove it in the next minor release (2.2). 2. JAR drop-in-ability is only guaranteed on point releases (2.4.1 is a drop-in replacement to 2.4.0). When switching to a ne

Re: Lucene's default settings & back compatibility

On Thu, May 21, 2009 at 6:53 PM, Marvin Humphrey wrote: > Lastly, I think a major java Lucene release is justified already. > Won't this discussion die down somewhat if you can get 3.0 out? Somewhat, yes, but then when working on 3.1 if we make some great improvement, I'd like new users in 3.1 t

Re: Lucene's default settings & back compatibility

OK it sounds like a single global actsAsVersion is too problematic. So how about, for cases where back compat default settings are important (analyzers, query scoring changes, etc.) we add actsAsVersion as a mandatory ctor argument to those classes (deprecating the other ctors)? We would do this

Re: Lucene's default settings & back compatibility

Perhaps it is wise to take a step back before we play all of these "what if" games... I think the best way forward is to simply ask ourselves, when confronted with an actual issue, is what is the cost of back compat. for this issue and then address it on a case by case basis, with a bias

Re: Lucene's default settings & back compatibility

Earwin Burrfoot wrote: As I said, my app uses around ten indexes, which one should I use? :) Even more here, this would be a reasonably painful solution for us. Matt - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.

Re: Lucene's default settings & back compatibility

> A funny thought: we can give those methods/classes really stupid/nasty names, > to emphasize the beauty of the existing API, to encourage people to stick > with the better API :) I believe I've seen google using internally names like thisisbadbadbadInstanceMap. :) > One thing we didn't address

Re: Lucene's default settings & back compatibility

> > Your example confused me. You're right. I Wrote it with one eye closed already. I meant to say that if I'm a 2.4 user and something gets deprecated in trunk (afterwards), it is carried through 2.4.X and 2.5 and then removed in 2.6. So only 1 full minor release. It's somewhat crazy, but what

Re: Lucene's default settings & back compatibility

On Thu, May 21, 2009 at 05:19:43PM -0400, Michael McCandless wrote: > Marvin, which solution would you prefer? Between the two, I'd prefer settings constructor arguments, though I would be inclined to have settings classes that are specific to individual classes rather than Lucene-wide. At lea

RE: Lucene's default settings & back compatibility

On 5/21/2009 at 7:17 AM, Michael McCandless wrote: > OK so it sounds like we've boiled the proposal down to two concrete > changes to the back-compat policy: > > 1) Default settings can change; we will always choose defaults > based on "latest & greatest for new users". This only > af

Re: Lucene's default settings & back compatibility

On Thu, May 21, 2009 at 5:55 PM, Michael McCandless < luc...@mikemccandless.com> wrote: > On Thu, May 21, 2009 at 5:44 PM, Robert Muir wrote: > > and what if your analyzer needs a third-party library (or two)? > > In such cases the back-compat of your analyzer is your responsibility, > right? I

Re: Lucene's default settings & back compatibility

On Thu, May 21, 2009 at 5:44 PM, Robert Muir wrote: > and what if your analyzer needs a third-party library (or two)? In such cases the back-compat of your analyzer is your responsibility, right? > i mean this isn't unique to analyzers, if something changes/bug is fixed in > the guts of some que

Re: Lucene's default settings & back compatibility

and what if your analyzer needs a third-party library (or two)? i mean this isn't unique to analyzers, if something changes/bug is fixed in the guts of some query/scorer that affects scoring in the slightest then thats a potential issue too, right? for a big index burying a result deep is effecti

Re: Lucene's default settings & back compatibility

On Thu, May 21, 2009 at 5:19 PM, Earwin Burrfoot wrote: >> Why not store an "actsAs" in the index, just for the changes that >> affect what's in the index?  Ie the index records the >> version that created it, and by default TokenStreams emulate their >> behavior as of that version? > > Because yo

Re: Lucene's default settings & back compatibility

On Thu, May 21, 2009 at 1:59 PM, Marvin Humphrey wrote: > That bug has led to 'base' having a compromised reputation among elite users > because of intermittent, inexplicable flakiness. Is that what you want for > Lucene? While I agree a single global default is not great, I do think it's the l

Re: Lucene's default settings & back compatibility

> Why not store an "actsAs" in the index, just for the changes that > affect what's in the index?  Ie the index records the > version that created it, and by default TokenStreams emulate their > behavior as of that version? Because you don't always have access to index at the time you create your T

Re: Lucene's default settings & back compatibility

On Thu, May 21, 2009 at 4:34 PM, Shai Erera wrote: > Changes to the index file formats need to be supported for 2 major releases. > I.e. 2.X indexes need to be read by 3.Y code, but not by 4.0. Agreed. > Method deprecations last for one full minor release. Your example confused me. I think i

Re: Lucene's default settings & back compatibility

Sounds like a good proposition. There's one problem I'd like to address. Good names for classes/members matter, and matter much. They directly affect how fast a newcomer is able to understand that particular API, it also affects how comfortable you work with it once you did understand. When we're

Re: Lucene's default settings & back compatibility

I thought we were actually on the track towards not introducing any Settings and/or actAs, but instead just change the policy? Can we agree on the following: * Changes to the index file formats need to be supported for 2 major releases. I.e. 2.X indexes need to be read by 3.Y code, but not by 4.0

Re: Lucene's default settings & back compatibility

I'm having trouble visualizing the various methods people are talking about. It seems like we could open an issue and post patches with code illustrating what each person is talking about? On Thu, May 21, 2009 at 10:02 AM, Michael McCandless < luc...@mikemccandless.com> wrote: > Actually, we sta

Re: Lucene's default settings & back compatibility

> That bug has led to 'base' having a compromised reputation among elite users > because of intermittent, inexplicable flakiness.  Is that what you want for > Lucene? While I agree with that point, Lucene already has lots and lots of static configuration. Having actsAsVersion won't add any new woes

Re: Lucene's default settings & back compatibility

Mike McCandless: > Well this is what I love about the actsAsVersion solution. There's no > pain for our back-compat users (besides the one-time effort to set > actsAsVersion), and new users always get the best settings. When some mad-as-hell user complains to this list after spending an inordina

Re: Lucene's default settings & back compatibility

Michael McCandless wrote: On Thu, May 21, 2009 at 12:19 PM, Robert Muir wrote: even as simple as changing default stopword list for some analyzer could be an issue, if the user doesn't re-index in response to that change. OK, right. So say we forgot to include "the" in the default En

Re: Lucene's default settings & back compatibility

Actually, we started with the *Settings classes (to hold defaults), but then realized a simple actsAsVersion (single static method) would suffice for just the back-compat settings and then pushed further and thought perhaps we should relax our back-compat policy entirely so emulating older versions

Re: Lucene's default settings & back compatibility

yeah, i was thinking the more likely case of where something like "teh" is in the list... On Thu, May 21, 2009 at 12:25 PM, Michael McCandless < luc...@mikemccandless.com> wrote: > On Thu, May 21, 2009 at 12:19 PM, Robert Muir wrote: > > even as simple as changing default stopword list for some

Re: Lucene's default settings & back compatibility

On Thu, May 21, 2009 at 12:46 PM, DM Smith wrote: > I'm looking forward to the repackaging effort. I'm looking forward to it too! I can't wait for NumericRangeQuery... But: someone with serious ant skill set, and some time, needs to get the itch here and start iterating... Mike --

Re: Lucene's default settings & back compatibility

On Thu, May 21, 2009 at 12:43 PM, Mark Miller wrote: > Hmmm - thats starting to sound nastier. Its another barrier to upgrading to > a new jar. I have to monitor/hunt down and not miss all these little flags > so that docs/terms don't disappear from my index? There is already some of > that and I

Re: Lucene's default settings & back compatibility

Sorry, I wasn't quite sure what to call this new class you guys have been talking about. I was referring to the class that's being discussed to encapsulate all of the defaults for a given lucene release. (Its caching strategies etc etc) I'm just not certain that something like a static list

Re: Lucene's default settings & back compatibility

Michael McCandless wrote: On Thu, May 21, 2009 at 8:24 AM, DM Smith wrote: On May 21, 2009, at 7:17 AM, Michael McCandless wrote: 1) Default settings can change; we will always choose defaults based on "latest & greatest for new users". This only affects "runtime behavior". E

Re: Lucene's default settings & back compatibility

Michael McCandless wrote: On Thu, May 21, 2009 at 12:19 PM, Robert Muir wrote: even as simple as changing default stopword list for some analyzer could be an issue, if the user doesn't re-index in response to that change. OK, right. So say we forgot to include "the" in the default En

Re: Lucene's default settings & back compatibility

What is the "lucene defaults class"? Mike On Thu, May 21, 2009 at 12:37 PM, Matthew Hall wrote: > For extreme examples like this, couldn't the stopword list be encapsulated > into a single class that's used by the lucene defaults class. > > That way if you folks released updates to mostly static

Re: Lucene's default settings & back compatibility

For extreme examples like this, couldn't the stopword list be encapsulated into a single class that's used by the lucene defaults class. That way if you folks released updates to mostly static content like a stopword list, new or old users could get it easily with a simple drop in fix? Just

Re: Lucene's default settings & back compatibility

On Thu, May 21, 2009 at 12:19 PM, Robert Muir wrote: > even as simple as changing default stopword list for some analyzer could be > an issue, if the user doesn't re-index in response to that change. OK, right. So say we forgot to include "the" in the default English stopwords list (yes, an extr

Re: Lucene's default settings & back compatibility

even as simple as changing default stopword list for some analyzer could be an issue, if the user doesn't re-index in response to that change. > Can you give an example of such changes? EG if we fix a bug in > StandardAnalyzer, we will default it to fixed for new users and expect > you on upgrad

Re: Lucene's default settings & back compatibility

On Thu, May 21, 2009 at 8:24 AM, DM Smith wrote: > > On May 21, 2009, at 7:17 AM, Michael McCandless wrote: > >>  1) Default settings can change; we will always choose defaults based >>    on "latest & greatest for new users".  This only affects "runtime >>    behavior".  EG in 2.9, when sorting b

Re: Lucene's default settings & back compatibility

On May 21, 2009, at 7:17 AM, Michael McCandless wrote: 1) Default settings can change; we will always choose defaults based on "latest & greatest for new users". This only affects "runtime behavior". EG in 2.9, when sorting by field you won't get scores by default. When we do th

Re: Lucene's default settings & back compatibility

On Thu, May 21, 2009 at 7:21 AM, Shai Erera wrote: > I thought that the index file format is supposed to be supported until the > 2nd major release. I.e. 3.0 will still read 2.0 indexes, but 4.0 won't. Is > that what you meant, or am I wrong? Woops, you're correct: http://wiki.apache.org/jaka

Re: Lucene's default settings & back compatibility

I thought that the index file format is supposed to be supported until the 2nd major release. I.e. 3.0 will still read 2.0 indexes, but 4.0 won't. Is that what you meant, or am I wrong? Shai On Thu, May 21, 2009 at 2:17 PM, Michael McCandless < luc...@mikemccandless.com> wrote: > OK so it sounds

Re: Lucene's default settings & back compatibility

OK so it sounds like we've boiled the proposal down to two concrete changes to the back-compat policy: 1) Default settings can change; we will always choose defaults based on "latest & greatest for new users". This only affects "runtime behavior". EG in 2.9, when sorting by field you

Re: Lucene's default settings & back compatibility

> > With the new way, you can get the first bug fix release, but then you will > quickly be left out of new bug fixes until you update your code. Mark, apologies for the late reference, but it struck me only after I left the computer yesterday. Again, I'm not sure how bit of a problem is it. Supp

Re: Lucene's default settings & back compatibility

On May 20, 2009, at 4:06 PM, Michael McCandless wrote: On Wed, May 20, 2009 at 3:24 PM, Shai Erera wrote: Then why go through all this trouble and not simply change the back- compat policy? Back-compat is insanely costly, especially the longer it takes us to get to the next major release..

Re: Lucene's default settings & back compatibility

Earwin Burrfoot wrote: That said, I see the points and value of relaxing the back compat policy as well. Its been discussed a lot in the past, and it has been eased in the past. Afraid to ask which additional shackles Lucene bore in the past. :) The easing wasn't that match. Offhand, I rem

Re: Lucene's default settings & back compatibility

Doug has said: "Lucene has a large install base. A > little effort towards back-compatibility on our part saves folks a lot > of effort." That's a good approach. Renaming a method, changing/adding some constructor parameters is really easy, you don't need to keep old thi

Re: Lucene's default settings & back compatibility

sing some headaches in Solr-dev-land (but at least it should be at the -dev level and not the -user level). We still should balance the "cost" of non back-compatible changes with the benefits. As Doug has said: "Lucene has a large install base. A little effort towards back-compatibility o

Re: Lucene's default settings & back compatibility

Shai Erera wrote: Thats not really the style Lucene has taken in the past :) Is it a back-compat policy? Maybe it's time to change that too ;) (kidding) Shai On Wed, May 20, 2009 at 11:39 PM, Mark Miller > wrote: Thats not really the style Lucene has

Re: Lucene's default settings & back compatibility

> > Thats not really the style Lucene has taken in the past :) Is it a back-compat policy? Maybe it's time to change that too ;) (kidding) Shai On Wed, May 20, 2009 at 11:39 PM, Mark Miller wrote: > Thats not really the style Lucene has taken in the past :) >

Re: Lucene's default settings & back compatibility

Shai Erera wrote: When the flood gates open, and code is rolling all over the place, upgrading Lucene becomes less of a buffet and more of a pain in the a** I slightly disagree with that. If I'm a 2.2 user and I silently upgraded to 2.4, 2.4.1 and 2.9 I will have loads of work to

Re: Lucene's default settings & back compatibility

> > When the flood gates open, and code is rolling all over the place, > upgrading Lucene becomes less of a buffet and more of a pain in the a** > I slightly disagree with that. If I'm a 2.2 user and I silently upgraded to 2.4, 2.4.1 and 2.9 I will have loads of work to do when I come to upgrade t

Re: Lucene's default settings & back compatibility

Shai Erera wrote: +1 (am I allowed to cast +1s not being a committer?) :) Absolutely :) When push comes to shove, you don't even have a valid vote as a Committer. Only members of the PMC have binding votes. You have as much voting power as a committer as long as you have as much an ability t

Re: Lucene's default settings & back compatibility

Earwin Burrfoot wrote: See, you upgrade either for new features, or for performance improvements. You have to write code for former, and you have to write code for the latter (because by default most of them are off). Mark Miller: If you have upgraded Lucene over the years and you never t

Re: Lucene's default settings & back compatibility

Earwin - I wrote it before - index structure is the only back-compat policy I propose to keep, and not for just one major release, but for 2 (which I believe is the current behavior already). I also absolutely don't want to give that up. I think it's not unreasonable to say "if you want to take ad

Re: Lucene's default settings & back compatibility

On Wed, May 20, 2009 at 3:24 PM, Shai Erera wrote: > Then why go through all this trouble and not simply change the back-compat > policy? OK so let's talk policy now ;) We need some serious relaxing of the back-compat policy to make the actsAsVersion proposal pointless. Ie whenever we want to c

Re: Lucene's default settings & back compatibility

Mark Miller: > If you have upgraded Lucene over the years and you never touched code to > tweak performance, you still got fantastic performance improvements. You just > didn't get them all. If you never touched the code over the years, your project is probably already dead. Shai Erera: > Exactl

Re: Lucene's default settings & back compatibility

Exactly ! which is why I think we should relax the back-compat policy "a bit". And ... (I realize it's going to complicate things a bit) we could also decide to have dot release for bug fixes, like we had 2.4.1. So let's say when 3.4 comes (3-4 years from now :) ). In 3.6 we don't preserve any bac

Re: Lucene's default settings & back compatibility

Earwin Burrfoot wrote: See, you upgrade either for new features, or for performance improvements. You have to write code for former, and you have to write code for the latter (because by default most of them are off). Thats not completely true. If you have upgraded Lucene over the years and you

Re: Lucene's default settings & back compatibility

In fact, there's no reason to upgrade Lucene (save for bigfixes), if you absolutely require a drop-in jar, and don't want to touch any of your code. See, you upgrade either for new features, or for performance improvements. You have to write code for former, and you have to write code for the latte

Re: Lucene's default settings & back compatibility

Then why go through all this trouble and not simply change the back-compat policy? Really, I read some of Grant's responses and I realize that I've upgraded to 2.4 way too long ago. 2.9 is nowhere in sight. It takes a lot of time to release and during that time there's lots of discussions on the m

Re: Lucene's default settings & back compatibility

On Wed, May 20, 2009 at 12:55 PM, Andi Vajda wrote: > I've been watching this thread with interest with my opinion swaying back > and forth. So have I! > This last comment, though, pushes me to favor the settings class idea > because that idea came with the promise of eliminating the combinator

  1   2   3   >