I think it should be more clear that the devs have not come to an agreement on this change yet, irregardless of the communities input.
Michael McCandless wrote: > Looks good! > > Mike > > On Tue, Oct 13, 2009 at 3:07 PM, Michael Busch <busch...@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-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > > -- - Mark http://www.lucidimagination.com --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
