:54 PM
Subject: Re: Going to Java 5. Was: Re: A bit of planning
All it takes is one line in the announcement saying "Version 3.0 uses
Java 1.5" I don't think the significance will be lost on anyone.
Everyone knows what Java 1.5 is. I'm -1 on calling it 4.0. People
will th
: I'm fine with the plan as far as I understand it, but can you clarify
: something for me?
:
: While 3.0 won't be backward compatible in that it requires Java 5.0, will it
: be otherwise backward compatible? That is, if I compile with 2.9, eliminate
: all deprecations and use Java 5, can I drop 3
Grant Ingersoll wrote:
All it takes is one line in the announcement saying "Version 3.0 uses
Java 1.5" I don't think the significance will be lost on anyone.
Everyone knows what Java 1.5 is. I'm -1 on calling it 4.0. People
will then ask where is 3.0. I am +1 for sticking w/ the plan we vo
All it takes is one line in the announcement saying "Version 3.0 uses
Java 1.5" I don't think the significance will be lost on anyone.
Everyone knows what Java 1.5 is. I'm -1 on calling it 4.0. People
will then ask where is 3.0. I am +1 for sticking w/ the plan we voted
for as describe
On Mon, Mar 10, 2008 at 9:21 PM, DM Smith <[EMAIL PROTECTED]> wrote:
> Grant Ingersoll wrote:
> > We voted to make 3.0 Java 1.5, full well knowing that it will break
> > the back compat. requirements. I don't see the point of postponing it
> > or dragging it out.
>
> I thought his suggestion was
Grant Ingersoll wrote:
We voted to make 3.0 Java 1.5, full well knowing that it will break
the back compat. requirements. I don't see the point of postponing it
or dragging it out.
I thought his suggestion was to skip 3.0 as a designator and instead use
4.0. If so, the schedule would not cha
We voted to make 3.0 Java 1.5, full well knowing that it will break
the back compat. requirements. I don't see the point of postponing it
or dragging it out.
On Mar 10, 2008, at 12:02 PM, Doron Cohen wrote:
On Thu, Jan 17, 2008 at 4:01 PM, DM Smith <[EMAIL PROTECTED]>
wrote:
On Jan 1
On Thu, Jan 17, 2008 at 4:01 PM, DM Smith <[EMAIL PROTECTED]> wrote:
>
> On Jan 17, 2008, at 1:38 AM, Chris Hostetter wrote:
>
> > : 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
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 ol
: 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 inde
On Jan 12, 2008, at 6:35 PM, Chris Hostetter wrote:
: Hmm, actually this is probably too restrictive. But maybe we could
say
: that Lucene 3.0 doesn't have to be able to read indexes built with
: versions older than 2.0?
that is in fact the position that lucene has had since as long as
i
Chris Hostetter wrote:
> : Hmm, actually this is probably too restrictive. But maybe we could say
> : that Lucene 3.0 doesn't have to be able to read indexes built with
> : versions older than 2.0?
>
> that is in fact the position that lucene has had since as long as i've ben
> involved with it..
: Hmm, actually this is probably too restrictive. But maybe we could say
: that Lucene 3.0 doesn't have to be able to read indexes built with
: versions older than 2.0?
that is in fact the position that lucene has had since as long as i've ben
involved with it...
http://wiki.apache.org/lucene-j
Michael Busch wrote:
>
> One question that came to my mind: What's our policy for file format
> backwards-compatibility? Is it the same as for APIs. That would mean
> that Lucene 3.0 would have to be able to read indexes built with 2.9 but
> not with earlier versions. I'd be all for such a policy,
I think we said that we wanted a 2.4 release. There are a bunch of
issues with Fix Version 2.4. And it would be nice to get them into 2.4
instead of 3.x, because some of them involve fairly big API changes,
like LUCENE-584 or LUCENE-831. Then we could get rid of all the
deprecated APIs in 3.0 and c
15 matches
Mail list logo
