On Jan 17, 2008, at 1:38 AM, Chris Hostetter wrote:
: If I remember right, the file format changed in 2.1, such that 2.0
could not
: read a 2.1 index.
that is totally within the bounds of the compatibility statement...
http://wiki.apache.org/lucene-java/BackwardsCompatibility
Note that older releases are never guaranteed to be able to read
indexes
generated by newer releases. When this is attempted, a predictable
error
should be generated.
: Release 3.0 will be the first to require Java 5. But we can't do
it as we did
: before, where the new api was introduced in the x.9 release, with
the old
: marked as deprecated. To do so would make 2.9 not be a drop in
replacement for
: 2.4.
there's no reason why new APIs can't be introduced in 2.9, new APIs
were
introduced in 1.9 and it was still a drop in replacemend for 1.4. The
only hitch that makes 3.0/2.9 differnet then 2.0/1.9 is that since
we're
going to start allowing JDK1.5 features in 3.0, any new APIs that
want to
use 1.5 *syntax* features have to wait until 3.0.
I guess I said it poorly. That is exactly what I meant.
This admittedly is where some discussion should probably happen,
because
this might mean that because of some design decisions about what
some new
API should look like, 2.9 gets some deprecation messages warning
people
that a method won't be supported in 3.0, without the replacement
method
existing in 2.9 (because it requires generics or some new standard
library
class that isn't in 1.4) making it imposisble for some apps to compile
against 2.9 without getting deprecation warnings. but personally i
don't
think that's not the end of the world, particularly if we make it
clear
that 2.9 is a transitional release.
But as i say: some discussion should probably happen.
Well said! There needs to be a discussion on how how Java 1.5 is used
in the API. Probably on it's own thread and summarized on a wiki page.
Personally, I don't care any near as much how it is used within methods.
Incidently, here is the summary of the discussion about the
2.4,2.9,3.0/1.5 plan ...
http://wiki.apache.org/lucene-java/Java_1%2e5_Migration
(the details of how deprecations and new 1.5 APIs and deprecations
in 2.9
should be dealt with is admittedly a little fuzzy in the wiki, i can't
remember if they were fleshed out in any more depth in on the mailing
list, and i don't have the energy to re-read it all now)
As far as I remember, they weren't fleshed out. I remember thinking at
the time that this would be a problem that could wait until we got
close to 2.9. Well, we are closer. :)
: I'd like to recommend that 3.0 contain the new Java 5 API changes
and what it
: replaces be marked deprecated. 3.0 would also remove what was
deprecated in
: 2.9. Then in 3.1 we remove the deprecations.
FWIW: This would violate the compatibility requirements, since code
that
compiles against 3.0 (with deprecation warnings) wouldn't compile
against
3.1 -- but then again: there has been some mention of revisting the
entire
back compatibility commitments of Lucene, and now certainly seems
like the time
to discuss that before too much work is done in any particular
direction
in an attempt to "head towards" 2.9/3.0.
Any way that it goes, my point is that it needs to be a two step
process. The additional step needs to address the language differences.
Maybe after 2.9, we add 2.9.5 (or whatever) that introduces the Java 5
APIs, with appropriate deprecations. 2.9.5 would require Java 1.5.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
