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