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 don't ever upgrade. Furthermore, when a reviewer (typically a "new user") tests Lucene against other search engines, and fails to check our Wiki for all the things we all know you have to do to get good search or indexing performance, and then reports in a well-read blog somewhere that Lucene's performance isn't great when compared to other search engines, and lots of other people read that, cite it, share it, etc., those people are less inclined to try Lucene. This then stunts Lucene's growth. Yes, we all sit here and say "well that's not a fair review because you didn't properly tune Lucene", yet, this kind of thing happens all the time. If Lucene had better defaults out of the box it'd reduce how often that happens. Mike On Fri, May 22, 2009 at 2:49 PM, DM Smith <dmsmith...@gmail.com> wrote: > Michael McCandless wrote: >> >> On Fri, May 22, 2009 at 2:27 PM, DM Smith <dmsmith...@gmail.com> 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 search >>>> app to >>>> not fail silently"? ;) A "new user" who follows your advice... >>>> >>>> // haha stupid noob StandardAnalyzer analyzer = new >>>> StandardAnalyzer(Versons.LATEST); >>>> >>>> ... is going to get screwed when the default tokenization behavior >>>> changes. >>>> And it would be much worse if we follow my preference for making the arg >>>> optional without following my preference for keeping defaults intact: >>>> >>>> // haha eat it luser StandardAnalyzer analyzer = new >>>> StandardAnalyzer(); >>>> >>>> It's either make the arg mandatory when changing default behavior and >>>> recommend that new users pass a fixed argument, or make it optional but >>>> keep >>>> defaults intact between major releases. >>>> >>> >>> I think I see your point: A new user is such only for the first release >>> that >>> they use Lucene. For a first use, there is no backward compatibility >>> problem. On the use of a subsequent release, their code still gets the >>> latest and greatest and now by the choice they were guided to make, they >>> may >>> have broken backward compatibility. >>> >>> So for any user, the only save, thus acceptable use is to never have >>> Versions.LATEST, but only a specific version. >>> >> >> Right, we would have to not provide Versions.LATEST, ie if you want >> latest, you'd pick Versions.LUCENE_29 (in 2.9). > > Why go to all this trouble for a new user? > > Let's pretend that there are 1,000 new users every release. After 12 > releases, there are still only 1000 new users but now 11000 old users. > > How does it help an old user? > > Those 11000 old users now have to update their code to Versions.Lucene_301 > (or whatever the latest is) to get the latest changes, but they are also > going to have to understand what that means and figure out what parts of > their application now behave in a broken manner. Where are they to go to > find out that info? CHANGES.txt? > > When I was a new user, I had to look at example code, read faqs, wiki, > javadoc, java-users .... It was a learning curve, fortunately not steep. > > Don't those resources need to be maintained so as to match the > best/recommended practices? Can't that be the place where new users are > informed? > > -- DM > > --------------------------------------------------------------------- > 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
