I'd vote A with following addition: What about creating major version more often?
If there are incremental improvements which don't clutter the code too much continue with 3.0 -> 3.1 -> 3.2 -> .. -> 3.X Once there are significant changes which are hard to maintain backward compatible start a 4.0 line. Just as you did before, just lower the threshold on what kind of changes force new major version release. For example in 2.9 release cycle at least AttributeSource stuff deserved a new major version. Uwe's Trie/Numeric fields, LUCENE-1483 and so on are incremental so could be minor releases. So upcoming 3.0 with java 1.5 and massive deprecation of old stuff would actually be at least 4.0. On Fri, Oct 16, 2009 at 10:39, Paul Elschot <paul.elsc...@xs4all.nl> wrote: > On Friday 16 October 2009 08:57:37 Michael Busch 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) > > I'd prefer B), with a minimum period of about two months to the > next release in case it removes deprecations. > > Regards, > Paul Elschot > --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
