Return-Path: Delivered-To: apmail-lucene-solr-dev-archive@minotaur.apache.org Received: (qmail 87710 invoked from network); 18 Mar 2010 15:33:52 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 18 Mar 2010 15:33:52 -0000 Received: (qmail 26077 invoked by uid 500); 18 Mar 2010 15:33:51 -0000 Delivered-To: apmail-lucene-solr-dev-archive@lucene.apache.org Received: (qmail 26028 invoked by uid 500); 18 Mar 2010 15:33:51 -0000 Mailing-List: contact solr-dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: solr-dev@lucene.apache.org Delivered-To: mailing list solr-dev@lucene.apache.org Received: (qmail 26020 invoked by uid 99); 18 Mar 2010 15:33:51 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 18 Mar 2010 15:33:51 +0000 X-ASF-Spam-Status: No, hits=0.7 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [209.85.160.176] (HELO mail-gy0-f176.google.com) (209.85.160.176) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 18 Mar 2010 15:33:44 +0000 Received: by gyd8 with SMTP id 8so1096974gyd.35 for ; Thu, 18 Mar 2010 08:33:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.4.12 with SMTP id g12mr1932403ybi.319.1268926402832; Thu, 18 Mar 2010 08:33:22 -0700 (PDT) In-Reply-To: <20100318132014.GA11342@rectangular.com> References: <748361B8-3282-470B-B9F5-561A07D55DEA@apache.org> <05DEB13A-564B-4E61-AB67-17D5749BCDC7@apache.org> <20100318132014.GA11342@rectangular.com> Date: Thu, 18 Mar 2010 10:33:22 -0500 Message-ID: <9ac0c6aa1003180833l19975560s2a589a9733e7400a@mail.gmail.com> Subject: Re: rough outline of where Solr's going From: Michael McCandless To: solr-dev@lucene.apache.org Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org On Thu, Mar 18, 2010 at 8:20 AM, Marvin Humphrey wrote: > I think the concern is what happens if Solr migrates a bunch of stuff into > Lucene, ceding control over crucial functionality, and then Solr wants to > release but Lucene does not. That would pose a problem for Solr, no? But, I don't think we'd ever do this -- ie when we release Solr we'll also release Lucene. Think about it... if for some exotic reason Lucene is unreleasable, then, presumably we would not up and release Solr until we fixed whatever was broken with Lucene, since it'd also break Solr. It is conceivable we could release only Lucene (yes, this was an explicit part of the vote, take 2), but I expect in practice that'll be the exception not the rule... it remains to be seen. On version numbering... my inclination would be to let Solr and Lucene use their own version numbers (don't sync them up). I know it'd simplify our lives to have the same version across the board, but these numbers are really for our users, telling them when big changes were made, back compat broken, etc. I think that trumps dev convenience. Mike