Mailing-List: contact solr-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: solr-dev@lucene.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-Id: <25C18E5B-47E7-443B-82F5-9768F62906D7@apache.org>
From: Grant Ingersoll <gsingers@apache.org>
To: solr-dev@lucene.apache.org
In-Reply-To: <49382957.6020705@gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Subject: Re: Backwards compatibility
Date: Fri, 5 Dec 2008 08:45:05 -0500
References: <49382957.6020705@gmail.com>


On Dec 4, 2008, at 2:02 PM, Michael Busch wrote:

> Hi,
>
> I was wondering what the backwards-compatibility rules in Solr are?  
> Is it the same as in Lucene, i.e. public and protected APIs can only  
> be changed in a major release (X.Y -> (X+1).0) ?
> I'd like to consolidate the function queries in Solr and Lucene and  
> it's gonna be quite messy if we have to keep all classes in Solr's  
> search/function package around.

Yes, it is more or less the same as Lucene, although we usually have a  
bit more flexibility on internals, since the public API is the Params  
and not necessarily a low-level API (w/ the exception of SolrJ).

See http://wiki.apache.org/solr/CommitPolicy

I think it makes sense to have a single search/function package shared  
instead of the current fork.  Can Lucene's now do everything that  
Solr's does with support for all the different functions and the  
ability to multiply the boost instead of just adding it?  (Correct me  
if I'm not understanding it, I'm going from what's possible as a user  
of Solr, I haven't looked at the code in a while, so that  
functionality may be implemented somewhere else)

-Grant