lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <luc...@mikemccandless.com>
Subject Re: Draft for java-user mail about backwards-compatibility policy changes
Date Tue, 13 Oct 2009 20:07:46 GMT
Looks good!

Mike

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


Mime
View raw message