> > If not, then our next release version should just be 2.0 and skip > > 1.9, don't ya think?
As other said - we want 1.9 + 2.0 so we can clean up deprecated stuff. > FWIW... One reason I haven't been persistent or hurried about the > UTF-8-clean/speedup patches is because they aren't backwards > compatible, and thus should not be considered prior to a 1.9 > release. The other is that I suspect that given sufficient effort, > byte-count Lucene strings will win out over char-chount Lucene > strings -- we'll know after I tinker with the merge process and > submit a diff. Again, I haven't been rushing -- I'm finishing up the > > Perl/C port of the org.apache.lucene.index package to familiarize > myself with all the nooks and crannies first. > > If you go directly to 2.0, when will the next opportunity be to > introduce a backwards-compatibility-killing index format change? I think 2.1 or 2 is a fair game. I believe 1.4.3 -> 1.9 indices are compatible. Just scanned CHANGES.txt for index incompatibility notes the other day and didn't find any. Otis --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
