Ryan McKinley wrote: >>> >>> 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. I agree with all of that - I just didn't understand starting a Solr back compat policy by ranking importance. Does that mean I don't have to strive for back compat with configuration with the same intensity as the URL API? I think the current policy of just doing our best and taking the situations as they come case-by-case works pretty well. When a backcompat issue comes up with configuration, should I be thinking, well, its not a URL API syntax, so ... I'd just consider the impact on users and do my best right? The same should apply to each of the cats.
Lucene has a back compat policy, but the reality is not that policy - its what I said above - we evaluate the impact on users and do our best, case-by-case. The policy isn't really totally in line with the reality. And Solr has appeared to me at least, to work in the same manner. > > >>> >>> 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 Okay - was just curious :) > > >>> >>> 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. Lucene works that way too though - case-by-case we determine the affect on users. Sometimes we say, eh, this won't affect that many, and that determines a break. I really don't think Lucene operates any different than Solr in the respect - other than its a bit more conservative (for good reason I think) - but it certainly doesn't treat everything the same across the board in terms of back compat. But neither do we prioritize everything in terms of importance - case-by-case we consider the impact. Or we just plain screw up and don't notice till too late ;) > > ryan > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org >
