lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Miller <>
Subject Re: Solr 1.5 or 2.0?
Date Fri, 20 Nov 2009 05:58:09 GMT
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
> - perhaps OSGi support/control/configuration
Okay - was just curious :)
>>> Lucene has an explict back-compatibility contract:
>>> 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:
> For additional commands, e-mail:

View raw message