On Mon, Jan 10, 2011 at 2:13 PM, Simon Willnauer < simon.willna...@googlemail.com> wrote:
> So moving stuff to modules has several advantages compared to trunk. I > think we all agree that we want lucene to be able to make use of this > functinality right?! So if we keep it in core we can either try to > make it right this time or we stick with bw compat for a long time > again risking that the same thing happens again and solr changes stuff > in incompatible ways. While this is a minor risk, I see FQ not really > a core part of lucene but rather something that is similar to > Analysis, a package with a small base interface (which could stay in > lucene core) and a large useful impl base like all the funcs in solr. > So it seems to me that modules is the right place for at least those > implemenations. > > does that make sense? > Do you mean that modules are not subject to backcompat guidelines? I was not ware of that. Relieving backcompat burden is a motivation by itself, but that asside, function query (or custom score query) seems like basic capability to me - it is not something that both Lucene and Solr are using, but rather something that Lucene is providing and Solr and user applications are using, right?
