Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-user@lucene.apache.org
Received-SPF: pass (athena.apache.org: domain of gopi.subramani@gmail.com
 designates 209.85.222.173 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=ctlvV+ZLlK/uhsJNyKLNJYY3D1zyYyZP1q4PcGrXs+RFF8aK74d9D9zs+c7730Xo/0
         OGykuaThKG0A3wxXSFLKcSNqw7UUe9FU9uwEeEIwwQ/1fmLjWuCX61A7YYMJ16GP1RIS
         wiHZweQlo6eS2sc6BNZbdPBBfB3kt9l43LNqQ=
MIME-Version: 1.0
In-Reply-To: <c68e39170910271814o36d0c0e3ve184dc2c525777c2@mail.gmail.com>
References: <4AD81961.7090108@gmail.com>
	 <2D127F11DC79714E9B6A43AC9458147F2F8EFAE2@suex07-mbx-03.ad.syr.edu>
	 <4AD8BEC4.50905@gmail.com> <4AD8C04E.2020101@gmail.com>
	 <4AD8C131.1080901@gmail.com> <4AE777AD.7000000@gmail.com>
	 <4AE77C06.3080600@gmail.com> <4AE7994E.3080305@gmail.com>
	 <c68e39170910271814o36d0c0e3ve184dc2c525777c2@mail.gmail.com>
Date: Fri, 30 Oct 2009 16:24:02 +0530
Message-ID: <733777220910300354v6c245be9pbb5a70806f21dc7e@mail.gmail.com>
Subject: Re: Proposal for changing Lucene's backwards-compatibility policy
From: Gopikrishnan Subramani <gopi.subramani@gmail.com>
To: java-user@lucene.apache.org
Content-Type: multipart/alternative; boundary=000e0cd2c0a490e4ef047724d87b

--000e0cd2c0a490e4ef047724d87b
Content-Type: text/plain; charset=ISO-8859-1

My vote is for option A. It's generally implied that a major version brings
in major changes (api as well as others), while the minor is, well, minor.
Why should that be broken for lucene? It would become increasingly difficult
for the lucene user community to catch up if they skipped one or two minors,
if that rule is broken.

-Gopi
On Wed, Oct 28, 2009 at 6:44 AM, Yonik Seeley <yonik@lucidimagination.com>wrote:

> On Tue, Oct 27, 2009 at 9:07 PM, Luis Alves <lafadev@gmail.com> wrote:
> > But there needs to be some forced push for these shorter major release
> > cycles,
> > to allow for code clean cycles to also be sorter.
>
> Maybe... or maybe not.
> There's also value in a more stable API over a longer period of time.
> Different people will pick a different balance, and it's not as simple
> as declaring that we need to be able to remove older APIs faster.
>
> -Yonik
> http://www.lucidimagination.com
>
> ---------------------------------------------------------------------
>  To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>
>

--000e0cd2c0a490e4ef047724d87b--