You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Yonik Seeley <yo...@lucidimagination.com> on 2009/11/19 02:53:04 UTC
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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Solr 1.5 or 2.0?
Posted by Noble Paul നോബിള് नोब्ळ् <no...@corp.aol.com>.
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 <uw...@thetaphi.de> wrote:
> We also had some (maybe helpful) opinions :-)
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
>
>> -----Original Message-----
>> From: yseeley@gmail.com [mailto:yseeley@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
>> <yo...@lucidimagination.com> 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-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
--
-----------------------------------------------------
Noble Paul | Principal Engineer| AOL | http://aol.com
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
RE: Solr 1.5 or 2.0?
Posted by Uwe Schindler <uw...@thetaphi.de>.
We also had some (maybe helpful) opinions :-)
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de
> -----Original Message-----
> From: yseeley@gmail.com [mailto:yseeley@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
> <yo...@lucidimagination.com> 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-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Solr 1.5 or 2.0?
Posted by Yonik Seeley <yo...@lucidimagination.com>.
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
<yo...@lucidimagination.com> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Solr 1.5 or 2.0?
Posted by Simon Willnauer <si...@googlemail.com>.
On Thu, Nov 19, 2009 at 2:53 AM, Yonik Seeley
<yo...@lucidimagination.com> 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-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Solr 1.5 or 2.0?
Posted by Ryan McKinley <ry...@gmail.com>.
switching back to solr-dev... sorry for spinning off that thread...
>>>
>>> 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
nice work! I had not seen this.
Re: Solr 1.5 or 2.0?
Posted by Noble Paul നോബിള് नोब्ळ् <no...@corp.aol.com>.
On Fri, Nov 20, 2009 at 6:30 AM, Ryan McKinley <ry...@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-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
--
-----------------------------------------------------
Noble Paul | Principal Engineer| AOL | http://aol.com
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Solr 1.5 or 2.0?
Posted by Mark Miller <ma...@gmail.com>.
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.
>
By the way, I don't disagree with this at all - I don't think now is
the time to decide this. We don't even know what's going to happen. I
just think it's interesting to see what comes out of the discussion. I
did think it was an odd time to have it though - makes more sense when
we see what actually happens. And *when* we actually end up releasing.
Re: Solr 1.5 or 2.0?
Posted by Mark Miller <ma...@gmail.com>.
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-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
Re: Solr 1.5 or 2.0?
Posted by Ryan McKinley <ry...@gmail.com>.
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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Solr 1.5 or 2.0?
Posted by Mark Miller <ma...@gmail.com>.
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-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
--
- Mark
http://www.lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Solr 1.5 or 2.0?
Posted by Ryan McKinley <ry...@gmail.com>.
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-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
RE: Solr 1.5 or 2.0?
Posted by Uwe Schindler <uw...@thetaphi.de>.
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: uwe@thetaphi.de
> -----Original Message-----
> From: yseeley@gmail.com [mailto:yseeley@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-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org