> > 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.

Uwe


---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org

Reply via email to