Re: Going to Java 5. Was: Re: A bit of planning
I agree with Grant and would prefer to see 3.0 to seeing 4.0 (down with inflation!) Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch - Original Message From: Grant Ingersoll <[EMAIL PROTECTED]> To: java-dev@lucene.apache.org Sent: Monday, March 10, 2008 4:05: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 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 <[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 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Going to Java 5. Was: Re: A bit of planning
: 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Going to Java 5. Was: Re: A bit of planning
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 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 <[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 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Going to Java 5. Was: Re: A bit of planning
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 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
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 <[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 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Going to Java 5. Was: Re: A bit of planning
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 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Going to Java 5. Was: Re: A bit of planning
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 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
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]
Re: A bit of planning
: 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A bit of planning
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A bit of planning
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A bit of planning
: 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A bit of planning
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A bit of planning
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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
