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]
