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 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 is not needed. > > So we no longer have the "defaults" class (*Settings). We may still > do it for the future (for its own benefits), but for just back-compat > of default settings, it seems like overkill. > > But I agree, the index altering cases are spooky. I think this'd make > me favor going back to the actsAsVersion option instead of the hard > flip on our back compat policy (at least for default settings; for API > changes I think 1 whole minor release may be reasonable). > > Mike > > On Thu, May 21, 2009 at 12:54 PM, Matthew Hall > <mh...@informatics.jax.org> wrote: > > 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 of words belongs > in a > > higher level defaults class like you guys are talking about, especially > > considering that anyone using a stop enabled analyzer really should be > > familiar with this list, and oftentimes needs to override it. > > > > Meh, now that I'm actually typing it out though, perhaps I'm incorrect > here, > > assuming this class you guys are describing will be well > > advertised/documented maybe it will actually make it easier for end > > developers to twiddle around with this list, or at least certainly make > them > > more aware that its even something that they have the ability to actually > > change. > > > > Matt > > > > Michael McCandless wrote: > >> > >> What is the "lucene defaults class"? > >> > >> Mike > >> > >> On Thu, May 21, 2009 at 12:37 PM, Matthew Hall > >> <mh...@informatics.jax.org> 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 content like a > >>> stopword list, new or old users could get it easily with a simple drop > in > >>> fix? > >>> > >>> Just my two cents. > >>> > >>> Matt > >>> > >>> Michael McCandless wrote: > >>> > >>>> > >>>> On Thu, May 21, 2009 at 12:19 PM, Robert Muir <rcm...@gmail.com> > 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 extreme example...). > >>>> > >>>> Under the proposed changes 1 & 2 to back-compat policy, we would add > >>>> "the" to the default stopword list, so new users get the fix, but > >>>> still keep the the-less list accessible (deprecated). We'd add an > >>>> entry in CHANGES.txt saying this happened, and then show code on how > >>>> to get back to the the-less stopword list. > >>>> > >>>> New users using that StopFilter would properly see "the" filtered out. > >>>> Users who upgraded would need to fix their code to switch back to the > >>>> deprecated the-less list. > >>>> > >>>> Mike > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > >>>> For additional commands, e-mail: java-dev-h...@lucene.apache.org > >>>> > >>>> > >>>> > >>> > >>> -- > >>> Matthew Hall > >>> Software Engineer > >>> Mouse Genome Informatics > >>> mh...@informatics.jax.org > >>> (207) 288-6012 > >>> > >>> > >>> > >>> --------------------------------------------------------------------- > >>> 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 > >> > >> > > > > > > -- > > Matthew Hall > > Software Engineer > > Mouse Genome Informatics > > mh...@informatics.jax.org > > (207) 288-6012 > > > > > > > > --------------------------------------------------------------------- > > 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 > >
