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

I'm not sure that this would be better though ... when i write my code, i 
pass "2.3" to all these constructors (or factory methods) and then later i 
want to upgrade to 2.3 to get all the new performance goodness ... i 
shouldn't have to change all those constructor calls to get all the 2.4 
goodness, i should be able to leave my code as is -- but if i do that, 
then i might not get all the 2.4 goodness, (like improved 
tokenization, or more precise segment merging) because some of that 
goodness violates previous assumptions that some code might have had ... 
my code doesn't have those assumptions, i know nothing about them, i'll 
take whatever behavior the Lucene Developers recommend (unless i see 
evidence that it breaks something, in which case i'll happily set a 
system property or something that the release notes say will force the 
old behavior.

The basic principle being: by default, give users the behavior that is 
generally viewed as "correct" -- but give them the option to force 
"uncorrect" legacy 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.

+1

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

i'm with you for the most part, it's just the defintion of "when truly 
required" that tends to hang people up ... there's a chicken vs egg 
problem of deciding wether the code should drive what the next release 
number is: "i've added a bitch'n feature but it requires adding a method 
to an interface, therefor the next release must be called 4.0" ... vs the 
mindset that "we just had a 3.0 release, it's too soon for another major 
release, the next release should be called 3.1, so we need to hold off on 
commiting non backwards compatible changes for a while."

I'm in the first camp: version numbers should be descriptive, information 
carrying, labels for releases -- but the version number of a release 
should be dicated by the code contained in that release.  (if that means 
the next version after 3.0.0 is 4.0.0, then so be it.)


-Hoss


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to