On Wed, Nov 21, 2012 at 12:33 AM, Ramprakash Ramamoorthy <youngestachie...@gmail.com> wrote: > On Tue, Nov 20, 2012 at 5:42 PM, Danil ŢORIN <torin...@gmail.com> wrote: > >> Ironically most of the changes are in unicode handling and standard >> analyzer ;) >> > > Ouch! It hurts then ;)
What we did going from 2 -> 3 (and in some cases where passing the right Version into a constructor didn't actually give the same behaviour as the old version... I'm looking at you, StandardTokenizer) was to archive copies of the classes from older versions of Lucene and layer our own backwards-compatible API on top of them. You just have to come up with a way to identify how something was indexed and support that forever (e.g. give all the Tokenizer and TokenFilter implementations unique names and never change the names.) The only time this really hurts is when Lucene change the API on something like TokenFilter and you have 20 or so implementations of it which you now have to update. It's a good example of how backwards compatibility slows down development time. The amount of work you have to do each time upstream changes something is more or less directly proportional to how long your application has been supported for. If I were making the decisions, I wouldn't support anything across major versions and you would just get an export/import tool for each version so you could bring the data across if you really wanted it. TX --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
