lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Busch <busch...@gmail.com>
Subject Re: Draft for java-user mail about backwards-compatibility policy changes
Date Wed, 14 Oct 2009 23:14:54 GMT
I will send the latest version of the draft to java-user in a few days 
if nobody objects.

  Michael

On 10/13/09 3:10 PM, Michael Busch wrote:
> OK, I made the draft a bit "more neutral" by pointing out the 
> downsides clearer. However, I think we have to explain reasons for and 
> against the change, otherwise people who didn't follow these 
> discussions on java-dev will have no idea why we actually want to make 
> a change at all. I added your sentences near the end. How's it now?
>
> Also looking at the 2.9 CHANGES.txt we have a pretty long compat-break 
> section, so the drop-in replacement guarantee isn't really one 
> anymore, which I didn't even mention in this draft.
>
> Draft:
>
> Hello Lucene users:
>
> In the past we have discussed our backwards-compatibility policy
> frequently on the Lucene developer mailinglist and we are thinking about
> making 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.
>
> The obvious downside of this proposal is that a simple jar drop-in
> replacement will not be possble 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.
>
> The developers haven't come to an agreement on this proposal yet.
> Potentionally giving up the drop-in replacement promise that Lucene
> could make in the past is the main reason for the struggle the developers
> are in and why we'd like to ask the user community for feedback to
> help us make a decision. After we gathered some 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.
>
> So please tell us which you prefer as a back compatibility policy for
> Lucene:
> A) best effort drop-in back compatibility for minor version numbers
> (e.g. v3.5 will be compatible with v3.2)
> B) best effort drop-in back compatibility for the next minor version
> number only, and deprecations may be removed after one minor release
> (e.g. v3.3 will be compat with v3.2, but not v3.4)
>
> Note that in any case the changes will take affect *after* the 3.0
> release.
>
> On behalf of the Lucene developers,
>  Michael Busch
>
>
>
> On 10/13/09 2:05 PM, Yonik Seeley wrote:
>> On Tue, Oct 13, 2009 at 4:25 PM, Michael Busch<buschmic@gmail.com>  
>> wrote:
>>> I've mentioned it several times on java-dev and LUCENE-1698 that I'd 
>>> like to
>>> ask the user
>>> community and nobody objected.
>> It's the old polling problem - how you ask influences the outcome (as
>> I said below), and you didn't say exactly how you were going to ask
>> before.
>>
>>>> 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?
>> Only if I was sure I wanted feedback :-)
>>
>> Which do you prefer as a back compatibility policy for Lucene:
>> A) best effort drop-in back compatibility for minor version numbers
>> (e.g. v3.5 will be compatible with v3.2)
>> B) best effort drop-in back compatibility for the next minor version
>> number only, and deprecations may be removed after one minor release
>> (e.g. v3.3 will be compat with v3.2, but not v3.4)
>>
>> In either case forward index format compatibility would be maintained
>> for an entire major version and the previous (e.g. v3.5 would be able
>> to read an index written by v2.2)
>>
>> http://www.lucidimagination.com
>> -Yonik
>>
>> ---------------------------------------------------------------------
>> 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


Mime
View raw message