Re: Solr 1.5 or 2.0?
On Fri, Nov 20, 2009 at 6:30 AM, Ryan McKinley wrote: > > On Nov 19, 2009, at 3:34 PM, Mark Miller wrote: > >> 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. > > I confess I don't know the details of the changes that have not yet been > integrated in solr -- the only lucene changes I am familiar with is what > was required for solr 1.4. > > > > >> >>> >>> 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. > > Just my luck... I'm batting 1000 :) > > But that means my code can upgrade to 3.0 without a issue now! > > >>> >>> 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. > > I think it is fair to suggest that people will have the most > stable/consistent/seamless upgrade path if you stick to the HTTP API (and by > extension most of the solrj API) > > I am not suggesting that the java APIs are not important and that > back-compatibly is not important. Solr has a some APIs with a clear > purpose, place, and intended use -- we need to take these very seriously. > We also have lots of APIs that are half baked and loosy goosy. If a > developer is working on the edges, i think it is fair to expect more hickups > in the upgrade path. > > >>> >>> 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 solr 1.5 with lucene 3.x is a good option. Solr 2.0 can have non-back compat changes for Solr itself. e.g removing the single core option , changing configuration, REST Api changes etc >> >> What is a serious change that would warrant a bump in your opinion? > > for example: > - config overhaul. detangle the XML from the components. perhaps using > spring. This is already done. No components read config from xml anymore SOLR-1198 > - major URL request changes. perhaps we change things to be more RESTful -- > perhaps let jersey take care of the URL/request building > https://jersey.dev.java.net/ > - perhaps OSGi support/control/configuration > > >>> >>> 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 :) > > i want to be nice. I just think that a different back compatibility > contract applies for solr then for lucene. It seems reasonable to consider > the HTTP API, configs, and java API independently. > > From my perspective, saying "solr 1.5 uses lucene 3.0" implies everything a > plugin developer using lucene APIs needs to know about the changes. > > To be clear, I am not against bumping to solr 2.0 -- I just have high > aspirations (yet little time) for what a 2.0 bump could mean for solr. > > ryan > > > - > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > > -- - Noble Paul | Principal Engineer| AOL | http://aol.com ---
Re: Solr 1.5 or 2.0?
On Nov 19, 2009, at 3:34 PM, Mark Miller wrote: 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. I confess I don't know the details of the changes that have not yet been integrated in solr -- the only lucene changes I am familiar with is what was required for solr 1.4. 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. Just my luck... I'm batting 1000 :) But that means my code can upgrade to 3.0 without a issue now! 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. I think it is fair to suggest that people will have the most stable/ consistent/seamless upgrade path if you stick to the HTTP API (and by extension most of the solrj API) I am not suggesting that the java APIs are not important and that back- compatibly is not important. Solr has a some APIs with a clear purpose, place, and intended use -- we need to take these very seriously. We also have lots of APIs that are half baked and loosy goosy. If a developer is working on the edges, i think it is fair to expect more hickups in the upgrade path. 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? for example: - config overhaul. detangle the XML from the components. perhaps using spring. - major URL request changes. perhaps we change things to be more RESTful -- perhaps let jersey take care of the URL/request building https://jersey.dev.java.net/ - perhaps OSGi support/control/configuration 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 :) i want to be nice. I just think that a different back compatibility contract applies for solr then for lucene. It seems reasonable to consider the HTTP API, configs, and java API independently. From my perspective, saying "solr 1.5 uses lucene 3.0" implies everything a plugin developer using lucene APIs needs to know about the changes. To be clear, I am not against bumping to solr 2.0 -- I just have high aspirations (yet little time) for what a 2.0 bump could mean for solr. ryan - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
Re: Solr 1.5 or 2.0?
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
Re: Solr 1.5 or 2.0?
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. 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). 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 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. 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 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
Re: Solr 1.5 or 2.0?
option 3 looks best . But do we plan to remove anything we have not already marked as deprecated? On Thu, Nov 19, 2009 at 8:10 PM, Uwe Schindler wrote: > We also had some (maybe helpful) opinions :-) > > - > Uwe Schindler > H.-H.-Meier-Allee 63, D-28213 Bremen > http://www.thetaphi.de > eMail: u...@thetaphi.de > > >> -Original Message- >> From: ysee...@gmail.com [mailto:ysee...@gmail.com] On Behalf Of Yonik >> Seeley >> Sent: Thursday, November 19, 2009 3:31 PM >> To: java-dev@lucene.apache.org >> Subject: Re: Solr 1.5 or 2.0? >> >> Oops... of course I meant to post this in solr-dev. >> >> -Yonik >> http://www.lucidimagination.com >> >> On Wed, Nov 18, 2009 at 8: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 > > -- - Noble Paul | Principal Engineer| AOL | http://aol.com - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
RE: Solr 1.5 or 2.0?
We also had some (maybe helpful) opinions :-) - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message- > From: ysee...@gmail.com [mailto:ysee...@gmail.com] On Behalf Of Yonik > Seeley > Sent: Thursday, November 19, 2009 3:31 PM > To: java-dev@lucene.apache.org > Subject: Re: Solr 1.5 or 2.0? > > Oops... of course I meant to post this in solr-dev. > > -Yonik > http://www.lucidimagination.com > > On Wed, Nov 18, 2009 at 8: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
Re: Solr 1.5 or 2.0?
Oops... of course I meant to post this in solr-dev. -Yonik http://www.lucidimagination.com On Wed, Nov 18, 2009 at 8: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
RE: Solr 1.5 or 2.0?
It depends on how much work it is to remove the rest of the not per-segment able stuff in Solr. If this can be done shortly, I would choose option 2 or 3 with no preference, as I do not know your backwards compatibility requirements. By the way, you wanted to send us your last Solr TokenStreams still using the old API? Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message- > From: ysee...@gmail.com [mailto:ysee...@gmail.com] On Behalf Of Yonik > Seeley > Sent: Thursday, November 19, 2009 2:53 AM > To: java-dev@lucene.apache.org > Subject: Solr 1.5 or 2.0? > > 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
Re: Solr 1.5 or 2.0?
On Thu, Nov 19, 2009 at 2:53 AM, 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 My first feeling is that Solr 2.0 with Lucene 3.x would be a clean cut. What is your back compat policy for major version jumps? > > -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
Solr 1.5 or 2.0?
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