noble.paul at corp
Nov 19, 2009, 9:45 PM
Post #10 of 10
(480 views)
Permalink
|
On Fri, Nov 20, 2009 at 6:30 AM, Ryan McKinley <ryantxu [at] gmail> 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-unsubscribe [at] lucene
> For additional commands, e-mail: java-dev-help [at] lucene
>
>
--
-----------------------------------------------------
Noble Paul | Principal Engineer| AOL | http://aol.com
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe [at] lucene
For additional commands, e-mail: java-dev-help [at] lucene
|
