One more thought on back compatibility:
Do we have the same requirements for any and all contrib modules? I
am especially thinking about the benchmark contrib, but it probably
applies to others as well.
-Grant
On Jan 24, 2008, at 8:42 AM, Grant Ingersoll wrote:
On Jan 24, 2008, at 4:27 AM, Michael McCandless wrote:
Grant Ingersoll wrote:
Yes, I agree these are what is about (despite the divergence into
locking).
As I see, it the question is about whether we should try to do
major releases on the order of a year, rather than the current 2+
year schedule and also how to best handle bad behavior when
producing tokens that previous applications rely on.
On the first case, we said we would try to do minor releases more
frequently (on the order of once a quarter) in the past, but this,
so far hasn't happened. However, it has only been one release,
and it did have a lot of big changes that warranted longer
testing. I do agree with Michael M. that we have done a good job
of keeping back compatibility. I still don't know if trying to
clean out deprecations once a year puts some onerous task on
people when it comes to upgrading as opposed to doing every two
years. Do people really have code that they never compile or work
on in over a year? If they do, do they care about upgrading? It
clearly means they are happy w/ Lucene and don't need any bug
fixes. I can understand this being a bigger issue if it were on
the order of every 6 months or less, but that isn't what I am
proposing. I guess my suggestion would be that we try to get back
onto the once a quarter release goal, which will more than likely
lead to a major release in the 1-1.5 year time frame. That being
said, I am fine with maintaining the status quo concerning back.
compatibility as I think those arguments are compelling. On the
interface thing, I wish there was a @introducing annotation that
could announce the presence of a new method and would give a
warning up until the version specified is met, at which point it
would break the compile, but I realize the semantics of that are
pretty weird, so...
I do think we should try for minor releases more frequently,
independent of the backwards compatibility question (how often to
do major releases) :)
+1
The question then becomes what can we do to improve our development
process?
I think major releases should be done only when a major feature
truly "forces" us to (which Java 1.5 has) and not because we want
to clean out the accumulated cruft we are carrying forward to
preserve backwards compatibility.
As for the other issue concerning things like token issues, I
think it is reasonable to fix the bug and just let people know it
will change indexing, but try to allow for the old way if it is
not to onerous. Chances are most people aren't even aware of it,
and thus telling them about may actually cause them to consider
it. For things like maxFieldLength, etc. then back compat. is a
reasonable thing to preserve.
So, in hindsight, the acronym/host setting for StandardAnalyzer
really should have defaulted to "true", meaning the bug is fixed,
but users who somehow depend on the bug (which should be a tiny
minority) have an avenue (setReplaceInvalidAcronym) to keep back
compatibility if needed even on a minor release, right? I agree.
(And so in 2.4 we should fix the default to true?).
I think for such issues where it's a very minor break in backwards
compatibility, we should make the break, and very carefully
document this in the "Changes in runtime behavior" section, even
within a minor release. I don't think such changes should drive us
to a major release.
+1
-Grant
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------
Grant Ingersoll
http://lucene.grantingersoll.com
http://www.lucenebootcamp.com
Lucene Helpful Hints:
http://wiki.apache.org/lucene-java/BasicsOfPerformance
http://wiki.apache.org/lucene-java/LuceneFAQ
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
