Catching up here...
Re the fracturing when Maven went from v1 -> v2: I think Lucene is a
totally different animal. Maven is an immense framework; Lucene is a
fairly small "core" set of APIs. I think for these "core" type
packages it's very important to keep drop-in compatibility as long as
possible.
I think we _really_ want our users to upgrade. Yes, there are alot of
A people who will forever be stuck in the past, but let's not make
barriers for them to switch to class C, or for class C to upgrade.
When someone is running old versions of Lucene it only hurts their (&
their friends & their users) perception of Lucene.
I think we've done a good job keeping backwards compatibility despite
some rather major recent changes:
* We now do segment merging in a BG thread
* We now flush by RAM (16 MB default) not at 10 buffered docs
* Merge selection is based on size of segment in bytes not doc count
* We will (in 2.4) "autoCommit" far less often (LUCENE-1044)
Now, we could have forced these into a major release instead, but, I
don't think we should have. As much as possible I think we should
keep on minor releases (keep backwards compatibility) so people can
always more easily upgrade.
As far as I know, the only solid reason for 3.0 is the
non-backwards-compatible switch to Java 1.5?
I do like the idea of a static/system property to match legacy
behavior. For example, the bugs around how StandardTokenizer
mislabels tokens (eg LUCENE-1100), this would be the perfect solution.
Clearly those are silly bugs that should be fixed, quickly, with this
back-compatible mode to keep the bug in place.
We might want to, instead, have ctors for many classes take a required
arg which states the version of Lucene you are using? So if you are
writing a new app you would pass in the current version. Then, on
dropping in a future Lucene JAR, we could use that arg to enforce the
right backwards compatibility. This would save users from having to
realize they are hitting one of these situations and then know to go
set the right static/property to retain the buggy behavior.
Also, backporting is extremely costly over time. I'd much rather keep
compatibility for longer on our forward releases, than spend our
scarce resources moving changes back.
So to summarize ... I think we should have (keep) a high tolerance for
cruft to maintain API compatibility. I think our current approach
(try hard to keep compatibility during "minor" releases, then
deprecate, then remove APIs on a major release; do major releases only
when truly required) is a good one.
Mike
Chris Hostetter wrote:
: To paraphrase a dead English guy: A rose by any other name is
still the same,
: right?
:
: Basically, all the version number tick saves them from is having
to read the
: CHANGES file, right?
Correct: i'm not disagreeing with your basic premise, just pointing
out
that it can be done with the current model, and that predicable
"version
identifiers" are a good idea when dealing with backwards
compatibility.
: Thus, the version numbers become meaningless; the question is
what do we see
: as best for Lucene? We could just as easily call it Lucene
Summer '08 and
: Lucene Winter '08. Heck, we could pull the old MS Word 2.0 to MS
Word 6.0 and
well .. i would argue that with what you hpothozied *then* version
numbers
would becoming meaningless ... having 3.0, 3.1, 3.2, 4.0 would be no
differnet then having 3, 4, 5, 6 -- our version numbers would be
identifiers with no other context ... i'm just saying we should
keep the
context in so that you know whether or not version X is backwards
compatible with version Y.
Which is not to say that we shouldn't hcange our version number
format...
Ie: we could start using quad-tuple version numbers: 3.2.5.0
instead of 3.5.0
3: major version #
identifies file format back compatibility (as today)
2: api compat version #
classes/methods may be removed when this changes
5: minor version #
new methods may be added when this changes (as today)
0: patch version #
changes only when there are serious bug fixes
...that might mean that our version numbers go...
3.0.0.0
3.0.1.0
3.1.0.0
3.1.1.0
3.1.2.0
3.2.0.0
...where most numbers never get above "2" but at least the version
number
conveys useful compatibility information (at no added developer
"cost")
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
