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