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 Tue, 13 Oct 2009 22:10:20 GMT
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