You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Grant Ingersoll <gs...@apache.org> on 2008/01/13 00:08:05 UTC
A bit of planning
I can't remember, did we say we are going to go to 2.4 or 2.9 next? I
suppose it depends a bit on 2.3, but I generally think we should move
onto 2.9 and then 3.0 fairly quickly.
Thoughts?
-Grant
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Going to Java 5. Was: Re: A bit of planning
Posted by Chris Hostetter <ho...@fucit.org>.
: 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.0 in and expect it to work
: without any further changes?
I think that point is still up in the air, and will depend largely on what
type of APIs start shapping up for 3.0. I suspect that when the time
comes, 2.9 may contain deprecations that refer forward to APIs that will
be availbale in 3.0, but won't exist in 2.9 ... so true drop in
compatibility may not be possible.
Then again: the main reason i suspect that is that i'm anticipating APIs
that use generics. i know that some weird things happen with generics and
bytecode, so it may actually be possible to intruduce non generic
(non-typesafe) versions of those APIs in 2.9 that people can compile
against that will be bytecode compatible with 3.0 -- i'm not sure.
(similar questions may come up with enum's and other misc langauge
features however)
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Going to Java 5. Was: Re: A bit of planning
Posted by DM Smith <dm...@gmail.com>.
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 voted
> for as described on
> http://wiki.apache.org/lucene-java/Java_1%2e5_Migration (last edited
> 10/1/2007) It's not like we are springing this on anyone. In fact,
> I'd be more than happy to announce it on the user list to let people
> know ahead of time.
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.0 in and
expect it to work without any further changes?
I think that is what I am reading wrt the plan.
DM
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Going to Java 5. Was: Re: A bit of planning
Posted by Grant Ingersoll <gs...@apache.org>.
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 described on http://wiki.apache.org/lucene-java/Java_1%2e5_Migration
(last edited 10/1/2007) It's not like we are springing this on
anyone. In fact, I'd be more than happy to announce it on the user
list to let people know ahead of time.
On Mar 10, 2008, at 3:52 PM, Doron Cohen wrote:
> On Mon, Mar 10, 2008 at 9:21 PM, DM Smith <dm...@gmail.com>
> 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 to skip 3.0 as a designator and
>> instead use
>> 4.0. If so, the schedule would not change.
>>
>
> Right, that's what I meant:
> * 2.9 with deprecations,
> * 3.0 removing deprecated stuff but still Java 1.4,
> * 4.0 first Java 5 version
> But I am catching up now a looong list of discussions and missed
> this vote, so I am ok with taking this back and proceed as voted.
> - Doron
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Going to Java 5. Was: Re: A bit of planning
Posted by Doron Cohen <cd...@gmail.com>.
On Mon, Mar 10, 2008 at 9:21 PM, DM Smith <dm...@gmail.com> 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 to skip 3.0 as a designator and instead use
> 4.0. If so, the schedule would not change.
>
Right, that's what I meant:
* 2.9 with deprecations,
* 3.0 removing deprecated stuff but still Java 1.4,
* 4.0 first Java 5 version
But I am catching up now a looong list of discussions and missed
this vote, so I am ok with taking this back and proceed as voted.
- Doron
Re: Going to Java 5. Was: Re: A bit of planning
Posted by DM Smith <dm...@gmail.com>.
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 change.
>
>
> On Mar 10, 2008, at 12:02 PM, Doron Cohen wrote:
>
>> On Thu, Jan 17, 2008 at 4:01 PM, DM Smith <dm...@gmail.com> 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 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.
>>
>>
>> Since going to Java 5 is a major change, I think it is not too wild to
>> go from 3.0 straight to 4.0..? Main (and perhaps only) change would be
>> moving to Java 5. This way we don't break any back.comp requirements.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Going to Java 5. Was: Re: A bit of planning
Posted by Grant Ingersoll <gs...@apache.org>.
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 <dm...@gmail.com>
> 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 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.
>
>
> Since going to Java 5 is a major change, I think it is not too wild to
> go from 3.0 straight to 4.0..? Main (and perhaps only) change would
> be
> moving to Java 5. This way we don't break any back.comp requirements.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: Going to Java 5. Was: Re: A bit of planning
Posted by Doron Cohen <cd...@gmail.com>.
On Thu, Jan 17, 2008 at 4:01 PM, DM Smith <dm...@gmail.com> 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 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.
Since going to Java 5 is a major change, I think it is not too wild to
go from 3.0 straight to 4.0..? Main (and perhaps only) change would be
moving to Java 5. This way we don't break any back.comp requirements.
Going to Java 5. Was: Re: A bit of planning
Posted by DM Smith <dm...@gmail.com>.
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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: A bit of planning
Posted by Chris Hostetter <ho...@fucit.org>.
: 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.
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.
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)
: 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.
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: A bit of planning
Posted by DM Smith <dm...@gmail.com>.
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've ben
> involved with it...
>
> http://wiki.apache.org/lucene-java/BackwardsCompatibility
>
>>> File formats are back-compatible between major versions. Version X.N
>>> should be able to read indexes generated by any version after and
>>> including version X-1.0, but may-or-may-not be able to read indexes
>>> generated by version X-2.N.
>
> 3.X must be able to read file created by 2.Y (where X and Y can be any
> number)
If I remember right, the file format changed in 2.1, such that 2.0
could not read a 2.1 index.
I seem to recall that 2.0 was 1.9 with the deprecations removed and
perhaps some minor changes.
I think we are going to need to do similar approach to change the file
formats but especially to go to Java 5.
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.
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.
While I was very vocal against going to Java 5, I'm very agreeable
with the change now. But, I'd like to see it be done in a consistent,
deliberate and well thought out manner. And I'd like to help out where
I can.
I still hope to "back port" any changes to Java 1.4.2, but with how
well the 2.x series performs, I am much less inclined to do so. Lucene
2.x is most excellent!!
-- DM Smith
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: A bit of planning
Posted by Michael Busch <bu...@gmail.com>.
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...
>
> http://wiki.apache.org/lucene-java/BackwardsCompatibility
>
>>> File formats are back-compatible between major versions. Version X.N
>>> should be able to read indexes generated by any version after and
>>> including version X-1.0, but may-or-may-not be able to read indexes
>>> generated by version X-2.N.
>
> 3.X must be able to read file created by 2.Y (where X and Y can be any
> number)
>
>
Oups, I should have read that page again before asking the question
here. Thanks for clarifying, Hoss.
I think 3.0 will be the first version which doesn't have to read all old
index formats then. (I don't think there was a 0.x release?)
-Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: A bit of planning
Posted by Chris Hostetter <ho...@fucit.org>.
: 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-java/BackwardsCompatibility
>> File formats are back-compatible between major versions. Version X.N
>> should be able to read indexes generated by any version after and
>> including version X-1.0, but may-or-may-not be able to read indexes
>> generated by version X-2.N.
3.X must be able to read file created by 2.Y (where X and Y can be any
number)
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: A bit of planning
Posted by Michael Busch <bu...@gmail.com>.
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, because that
> would clean up some classes significantly.
>
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?
-Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: A bit of planning
Posted by Michael Busch <bu...@gmail.com>.
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 clean up the code.
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, because that
would clean up some classes significantly.
-Michael
Grant Ingersoll wrote:
> I can't remember, did we say we are going to go to 2.4 or 2.9 next? I
> suppose it depends a bit on 2.3, but I generally think we should move
> onto 2.9 and then 3.0 fairly quickly.
>
> Thoughts?
>
> -Grant
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org