On Thu, May 21, 2009 at 4:34 PM, Shai Erera <ser...@gmail.com> 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 if in 2.1 we deprecate a method, then in 2.2 we can remove it? Or are you saying it's not until 2.3 that we can remove it (2 full minor releases)? > What I don't like about actsAs, and perhaps I just don't understand the > proposal well, is that I'm not sure where it's added. Will it be added to > IndexWriter, which will pass it on to all the classes it will meet/use? We would add say oal.Versions class, that has a static actsAs method and static constants. If back-compat is vital to your app you'd do: Versions.actsAs(Version.LUCENE_24) on upgrading to 2.9. Else, you do nothing to get "latest & greatest". You call this once in your app up front, and then use Lucene normally. Then, when IndexSearcher is asked to do field sorting, it consults actsAs to decide whether it should do scoring or not. > Changes to default behaviors, bug fixes or improvements, that may compromise > the index structure or indexed data (such as InvalidAcronym) will last for at > least one major release, if not 2 I think this harms new users unnecessarily (ie, I'd rather do actsAs than this). I'd like StopFilter to not discard positional information, fixes for bugs in StandardAnalyzer, and a correction to the default stopwords list, to be immediately available for new users on the next release. 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? Mike --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
