On May 20, 2009, at 4:06 PM, Michael McCandless wrote:
On Wed, May 20, 2009 at 3:24 PM, Shai Erera <ser...@gmail.com> wrote:
Then why go through all this trouble and not simply change the back-
compat
policy?
Back-compat is insanely costly, especially the longer it takes us to
get to the next major release... yet, the specific cost that bothers
me the most is that we hurt our new users because of the back-compat
users. It hurts Lucene's adoption/growth.
Another consideration on relaxing policy is that back-compat is well
nigh impossible to actually achieve. We spend an insane amount of our
energy maintaining back-compat, but then one accidental breakage that
slips through quickly causes many back-compat users to conclude we are
not back-compat. It's not much bang and alot of buck.
It is tempting to change our policy to something like:
* Bug fixes only on each 2.4.X release
* Anything can change on each 2.X release, but any prior 2.Y index
format is readable
I think it's not unreasonable to say "if you want to take advantage of
Lucene's perf improvements and new features, on upgrading you'll have
to recompile, fix APIs, etc.".
All reasonable, Mike. My take is that Lucene has always been
pragmatic about darn near everything, except back compat, where we are
pretty dogmatic.
In general, I think it is reasonable to say that even from 2.x to 2.y
we will try to be back compatible, but when we deem it necessary, we
reserve the right to change things. I don't think anyone here is
suggesting we would ever do something drastic like a complete overhaul
of all the APIs in a version change. I also think it is reasonable to
deprecate things by saying @deprecated Will be removed in 2.Y. Use
coolNewMethod instead. In other words, we keep deprecated around for
only one or two versions. Of course, the timing can vary. Things
like changing the Document stuff like we've talked about might last
longer (or shorter, actually) while minor deprecations may only be
kept for one. The index compatibility stuff is a must.
It is probably worthwhile to ask on java-user@ how many people rely on
our back compat policies.
<tongue in cheek> Of course, we do already support back compat for all
versions: svn checkout http://svn.apache.org/repos/asf/lucene/java/tags/lucene_2_3_1/
</tongue in cheek>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
