Ryan McKinley wrote: > I would love to set goals that are ~3 months out so that we don't have > another 1 year release cycle. For a 2.0 release where we could have > more back-compatibly flexibility, i would love to see some work that > may be too ambitious... In particular, the config spaghetti needs > some attention. > > I don't see the need to increment solr to 2.0 for the lucene 3.0 > change -- of course that needs to be noted, but incrementing the major > number in solr only makes sense if we are going to change *solr* > significantly. Lucene major numbers don't work that way, and I don't think Solr needs to work that way be default. I think major numbers are better for indicating backwards compat issues than major features with the way these projects work. Which is why Yonik mentions 1.5 with weaker back compat - its not just the fact that we are going to Lucene 3.x - its that Solr still relies on some of the API's that won't be around in 3.x - they are not all trivial to remove or to remove while preserving back compat.
> > The lucene 2.x -> 3.0 upgrade path seems independent of that to me. I > would even argue that with solr 1.4 we have already required many > lucene 3.0 changes -- All my custom lucene stuff had to be reworked to > work with solr 1.4 (tokenizers & multi-reader filters). Many - but certainly not all. > > In general, I wonder where the solr back-compatibility contract > applies (and to what degree). For solr, I would rank the importance as: > #1 - the URL API syntax. Client query parameters should change as > little as possible > #2 - configuration > #3 - java APIs Someone else would likely rank it differently - not everyone using Solr even uses HTTP with it. Someone heavily involved in custom plugins might care more about that than config. As a dev, I just plainly rank them all as important and treat them on a case by case basis. > > With that in mind, i think 'solr 1.5 with lucene 3.x' makes the most > sense. Unless we see making serious changes to solr that would > warrent a major release bump. What is a serious change that would warrant a bump in your opinion? > > Lucene has an explict back-compatibility contract: > http://wiki.apache.org/lucene-java/BackwardsCompatibility > > I don't know if solr has one... if we make one, I would like it to > focus on the URL syntax+configuration Its not nice to give people plugins and then not worry about back compat for them :) > > ryan > > > > On Nov 18, 2009, at 5:53 PM, Yonik Seeley wrote: > >> What should the next version of Solr be? >> >> Options: >> - have a Solr 1.5 with a lucene 2.9.x >> - have a Solr 1.5 with a lucene 3.x, with weaker back compat given all >> of the removed lucene deprecations from 2.9->3.0 >> - have a Solr 2.0 with a lucene 3.x >> >> -Yonik >> http://www.lucidimagination.com >> >> --------------------------------------------------------------------- >> 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 > -- - Mark http://www.lucidimagination.com --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org