Return-Path: Delivered-To: apmail-lucene-java-dev-archive@www.apache.org Received: (qmail 97990 invoked from network); 9 Feb 2007 21:00:18 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 9 Feb 2007 21:00:18 -0000 Received: (qmail 6943 invoked by uid 500); 9 Feb 2007 21:00:23 -0000 Delivered-To: apmail-lucene-java-dev-archive@lucene.apache.org Received: (qmail 6891 invoked by uid 500); 9 Feb 2007 21:00:22 -0000 Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: java-dev@lucene.apache.org Delivered-To: mailing list java-dev@lucene.apache.org Received: (qmail 6880 invoked by uid 99); 9 Feb 2007 21:00:22 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 09 Feb 2007 13:00:22 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (herse.apache.org: local policy) Received: from [204.127.192.84] (HELO rwcrmhc14.comcast.net) (204.127.192.84) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 09 Feb 2007 13:00:11 -0800 Received: from [192.168.168.15] (c-71-202-24-246.hsd1.ca.comcast.net[71.202.24.246]) by comcast.net (rwcrmhc14) with ESMTP id <20070209205951m1400lp507e>; Fri, 9 Feb 2007 20:59:51 +0000 Message-ID: <45CCE0C6.1080600@apache.org> Date: Fri, 09 Feb 2007 12:59:50 -0800 From: Doug Cutting User-Agent: Thunderbird 1.5.0.9 (X11/20070103) MIME-Version: 1.0 To: java-dev@lucene.apache.org Subject: Re: NewIndexModifier - - - DeletingIndexWriter References: <204416.59450.qm@web50310.mail.yahoo.com> <45CB8C56.2000701@mikemccandless.com> <45CBA430.2010100@mikemccandless.com> <45CCAF46.40900@apache.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Yonik Seeley wrote: > As long as you wouldn't object to a org.apache.lucene package in Solr... > With the understanding of course, that the onus would be on Solr developers > to keep up with any changes. I wouldn't object to that. Would you? Solr's developers are pretty on-top of Lucene and should thus be better able to track things than most. I think that's preferable to introducing a new public API with the expectation of deprecating it soon. It's not an ideal solution. Does anyone have a better proposal? Doug --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org For additional commands, e-mail: java-dev-help@lucene.apache.org