On Fri, Nov 20, 2009 at 6:30 AM, Ryan McKinley <ryan...@gmail.com> 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 --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
