Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Received-SPF: pass (nike.apache.org: domain of buschmic@gmail.com designates
 72.14.220.159 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=pG2IZSrFkBdowtZXrA14sG+4+Q82xyxUMcO8nsZLV5nUuY3T/MCW9VP1WvFgCGBx1m
         cmiCBjpogkEjTNw21pNVCvx1bxlSRXTT8pLjpJzPk/k0eScjTF9HrI6/YnuwccFRNItQ
         iXEU/fv5KkgdBAzfpPrnDwtoIv0sZiMwJut+4=
Message-ID: <4AD4E231.3050404@gmail.com>
Date: Tue, 13 Oct 2009 13:25:21 -0700
From: Michael Busch <buschmic@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
 rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4
MIME-Version: 1.0
To: java-dev@lucene.apache.org
Subject: Re: Draft for java-user mail about backwards-compatibility policy
 	changes
References: <4AD4CFDD.1050606@gmail.com>
 <c68e39170910131318o5234e7eeh7f4890b890d2818d@mail.gmail.com>
In-Reply-To: <c68e39170910131318o5234e7eeh7f4890b890d2818d@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 10/13/09 1:18 PM, Yonik Seeley wrote:
> I think I'm against sending such a request for feedback - and I think
> we already know what the results will be.
>    

I've mentioned it several times on java-dev and LUCENE-1698 that I'd 
like to ask the user
community and nobody objected.

> The email reads like "we want to do this, OK?" - and the beneficiaries
> of what is a volunteer effort are likely to respond overwhelmingly
> "OK!".  One could take the reverse position and probably get just as
> many positive responses.
>
>    
> Devs should decide, and if feedback is needed to help that, a neutral
> way of asking should be used.
>
>    
Do you want to draft a new mail?

  Michael

> -Yonik
> http://www.lucidimagination.com
>
> On Tue, Oct 13, 2009 at 3:07 PM, Michael Busch<buschmic@gmail.com>  wrote:
>    
>> Hi all,
>>
>> I wrote a draft for a mail I'd like to send to java-user to get some
>> feedback about the proposed changes to our backwards-compatibility policy we
>> discussed here and on LUCENE-1698.
>> Let me know what you think please!
>>
>>   Michael
>>
>>
>> Hello Lucene users:
>>
>> In the past we have discussed our backwards-compatibility policy
>> frequently on the Lucene developer mailinglist and we are very tempted
>> to make some significant changes. In this mail I'd like to outline the
>> proposed changes to get some feedback from the user community.
>>
>> Our current backwards-compatibility policy regarding API changes
>> states that we can only make changes that break
>> backwards-compatibility in major releases (3.0, 4.0, etc.); the next
>> major release is the upcoming 3.0.
>>
>> Given how often we made major releases in the past in Lucene this
>> means that deprecated APIs need to stay in Lucene for a very long
>> time. E.g. if we deprecate an API in 3.1 we'll have to wait until 4.0
>> before we can remove it. This means that the code gets very cluttered
>> and adding new features gets somewhat more difficult, as attention has
>> to be paid to properly support the old *and* new APIs for a quite long
>> time.
>>
>> The current policy also leads to delaying a last minor release before
>> a major release (e.g. 2.9), because the developers consider it as the
>> last chance for a long time to introduce new APIs and deprecate old ones.
>>
>> The proposal now is to change this policy in a way, so that an API can
>> only be removed if it was deprecated in at least one release, which
>> can be a major *or* minor release. E.g. if we deprecate an API and
>> release it with 3.1, we can remove it with the 3.2 release.
>>
>> For users this means of course that a simple jar drop-in replacement
>> won't be possible anymore with almost every Lucene release (excluding
>> bugfix releases, e.g. 2.9.0->2.9.1). However, you can be sure that if
>> you're using a non-deprecated API it will be in the next release.
>>
>> Note that of course these proposed changes do not affect
>> backwards-compatibility with old index formats. I.e. it will still be
>> possible to read all 3.X indexes with any Lucene 4.X version.
>>
>> Our main goal is to find the right balance between
>> backwards-compatibility support for all the Lucene users out there and
>> fast and productive development of new features. If we get positive
>> feedback here we will call a vote on the development mailinglist where
>> the committers have to officially decide whether to make these changes or
>> not.
>>
>> Note that in any case the changes will take affect *after* the 3.0
>> release.
>>
>> On behalf of the Lucene developers,
>>   Michael Busch
>>      
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
>    


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org