Hello Michael, I also would prefer B - it also shortens the time to have a benefit of new Lucene features in our applications. It forces our lazy programmers (I am of course ;) ) to deal with them - and reduces the efford to change to a major release afterwards. Maybe some minimum time waiting before removing a deprecated API would be nice, such as the 2 months Paul mentioned
regards Chris On Thu, 15 Oct 2009 23:57:37 -0700 Michael Busch <busch...@gmail.com> wrote: > 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 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. > > 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
signature.asc
Description: PGP signature
