Return-Path: Delivered-To: apmail-lucene-dev-archive@www.apache.org Received: (qmail 8552 invoked from network); 22 Apr 2010 14:58:21 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 22 Apr 2010 14:58:21 -0000 Received: (qmail 94015 invoked by uid 500); 22 Apr 2010 14:58:20 -0000 Delivered-To: apmail-lucene-dev-archive@lucene.apache.org Received: (qmail 93965 invoked by uid 500); 22 Apr 2010 14:58:20 -0000 Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@lucene.apache.org Delivered-To: mailing list dev@lucene.apache.org Received: (qmail 93958 invoked by uid 99); 22 Apr 2010 14:58:20 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 22 Apr 2010 14:58:20 +0000 X-ASF-Spam-Status: No, hits=0.5 required=10.0 tests=AWL,HTML_MESSAGE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [85.25.71.29] (HELO mail.troja.net) (85.25.71.29) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 22 Apr 2010 14:58:13 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.troja.net (Postfix) with ESMTP id EF478D36005 for ; Thu, 22 Apr 2010 16:57:50 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mail.troja.net Received: from mail.troja.net ([127.0.0.1]) by localhost (megaira.troja.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UuXridP7hxNt for ; Thu, 22 Apr 2010 16:57:42 +0200 (CEST) Received: from VEGA (WDC-MARE.marum.de [134.102.249.74]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.troja.net (Postfix) with ESMTPSA id EE89ED36001 for ; Thu, 22 Apr 2010 16:57:41 +0200 (CEST) From: "Uwe Schindler" To: References: <4BD05788.3000000@gmail.com> <005901cae22a$e24d6ff0$a6e84fd0$@de> In-Reply-To: Subject: RE: Proposal about Version API "relaxation" Date: Thu, 22 Apr 2010 16:57:51 +0200 Message-ID: <006401cae22c$2eab0a00$8c011e00$@de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0065_01CAE23C.F233DA00" X-Mailer: Microsoft Office Outlook 12.0 Thread-index: AcriK55AWV8qZvnKRvaTnW0PHXRCsgAAF99w Content-language: de ------=_NextPart_000_0065_01CAE23C.F233DA00 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable But you need one, if you want to backwport some feature. My point was, = that if you are planning to backport something, its better to start = developing on stable, as else you can possibly get problems when you = only have a clean API without any idea how to implement a backwards. =20 So for features that should be backported, start to plan with backwards = in mind from the beginning. =20 ----- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: uwe@thetaphi.de =20 From: Robert Muir [mailto:rcmuir@gmail.com]=20 Sent: Thursday, April 22, 2010 4:53 PM To: dev@lucene.apache.org Subject: Re: Proposal about Version API "relaxation" =20 =20 On Thu, Apr 22, 2010 at 10:48 AM, Uwe Schindler wrote: Hi Robert, =20 My main problem with devleoping new features on trunk first and then = porting by adding backwards cruft is, that you first don=E2=80=99t care = with backwards and then suddenly have to think about it. This may change = the API on trunk again, to get nearer to backwards or maybe because a = backwards layer is not possible. E.g. at the beginning of = AttributeSource-TokenStream API, when Michael and me discussed about the = sophisticated=C2=AE backwards layer, we also did some changes to the new = TokenStream API, to support backwards better. I think with this proposal things like sophisticated(R) backwards layers = would generally become a thing of the past...=20 --=20 Robert Muir rcmuir@gmail.com ------=_NextPart_000_0065_01CAE23C.F233DA00 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

But you need one, if you want to backwport some feature. = My point was, that if you are planning to backport something, its better to = start developing on stable, as else you can possibly get problems when you = only have a clean API without any idea how to implement a = backwards.

 

So for features that should be backported, start to plan = with backwards in mind from the beginning.

 

-----

Uwe Schindler

H.-H.-Meier-Allee 63, D-28213 = Bremen

http://www.thetaphi.de<= /p>

eMail: uwe@thetaphi.de

 

From:= Robert = Muir [mailto:rcmuir@gmail.com]
Sent: Thursday, April 22, 2010 4:53 PM
To: dev@lucene.apache.org
Subject: Re: Proposal about Version API = "relaxation"

 

 

On Thu, Apr 22, 2010 at 10:48 AM, Uwe Schindler = <uwe@thetaphi.de> = wrote:

Hi = Robert,

 

My main problem = with devleoping new features on trunk first and then porting by adding = backwards cruft is, that you first don=E2=80=99t care with backwards and then = suddenly have to think about it. This may change the API on trunk again, to get nearer to backwards or maybe because a backwards layer is not possible. E.g. at = the beginning of AttributeSource-TokenStream API, when Michael and me = discussed about the sophisticated=C2=AE backwards layer, we also did some changes = to the new TokenStream API, to support backwards better.


I think with this proposal things like sophisticated(R) backwards layers = would generally become a thing of the past...


--
Robert Muir
rcmuir@gmail.com

------=_NextPart_000_0065_01CAE23C.F233DA00--