Return-Path: Delivered-To: apmail-lucene-java-dev-archive@www.apache.org Received: (qmail 40415 invoked from network); 15 Apr 2010 19:49:01 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 15 Apr 2010 19:49:01 -0000 Received: (qmail 87077 invoked by uid 500); 15 Apr 2010 19:49:00 -0000 Delivered-To: apmail-lucene-java-dev-archive@lucene.apache.org Received: (qmail 87029 invoked by uid 500); 15 Apr 2010 19:49:00 -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 87022 invoked by uid 99); 15 Apr 2010 19:49:00 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 15 Apr 2010 19:49:00 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of vajda@osafoundation.org designates 149.20.54.96 as permitted sender) Received: from [149.20.54.96] (HELO leka.osafoundation.org) (149.20.54.96) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 15 Apr 2010 19:48:54 +0000 Received: from dhcp-wired-145.corp.631h.metaweb.com (nat09.metaweb.com [208.68.111.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by leka.osafoundation.org (Postfix) with ESMTP id C32A577D6F9 for ; Thu, 15 Apr 2010 12:48:33 -0700 (PDT) Date: Thu, 15 Apr 2010 12:50:02 -0700 (PDT) From: Andi Vajda X-X-Sender: vajda@dhcp-wired-145.corp.631h.metaweb.com Reply-To: Andi Vajda To: java-dev@lucene.apache.org Subject: Re: Proposal about Version API "relaxation" In-Reply-To: Message-ID: References: <4BC74D3E.1090106@gmail.com> <4BC754D0.1030406@gmail.com> User-Agent: Alpine 2.01 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Thu, 15 Apr 2010, Robert Muir wrote: > > > 2010/4/15 Michael McCandless > > I realize the migration tool has issues -- it fixes the hard > changes > but silently allows the soft changes to break (ie, your > analyzers my > not produce the same tokens, until we move all core analyzers > outside > of core, so they are separately versioned), but it seems like a > good > compromise here? > > > Well, lets consider doing that too. Since analyzers have this tough problem > of being "soft changes", I propose the following: > 1. get rid of version > 2. minimize the interface between the indexer and analysis > 3. put analyzers in their own versioned jar files. Yes, every analyzer needs to have its own version and thus, jar file. Putting all analyzers into one versioned jar file joins them at the hip and suffers from the same versioning and compat problems we're currently facing in core. Andi.. > > this way, we could provide a realistic capability for users to use > lucene-3.5.jar with lucene-3.2-analyzers.jar, and possibly have STRONGER > analyzer back compat (e.g. if we minimize the damn thing enough, perhaps > very old analyzers.jar's could even work across major releases). > > its also much safer when you are using the same bytecodes you used before, > instead of hairy back compat layers. I don't refer to Uwe's code here: its > perfect, but we cant force Uwe into writing the back compat for every big > feature. > > -- > Robert Muir > rcmuir@gmail.com > > --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org For additional commands, e-mail: java-dev-help@lucene.apache.org