lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler" <>
Subject RE: Proposal for changing Lucene's backwards-compatibility policy
Date Fri, 16 Oct 2009 11:46:27 GMT
> > So please tell us which you prefer as a back compatibility policy for
> > Lucene:
> I don't do drop in but recompile anyway, so it doesn't matter for me.
> It is only important that the documentation is clear about what has to
> be done.
> > 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)
> Nevertheless I prefer B because the deprecation changes per release will
> be smaller and maybe even grouped by topic. I prefer advancing step by
> step. A bunch of deprecated API parts even hinders reading and
> understanding the API. So, the sooner they are gone, the better.

+1 Even for me as a core developer, it's always a pain to find out: Is it
TopDocsCollector, TopFieldDocCollector and other, which are the right one.
The names of these classes in 2.9 and the mix between deprecated and not
deprecated is a hell!

In my opinion, we should more often release major releases. And this always
using a short-time x.9 -> (x+1).0. So new API in .9 and then 2 month later
release the major release.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message