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 <gr...@gmail.com> on 2007/08/02 14:28:35 UTC
Re: [VOTE] Migrate Lucene to JDK 1.5 for 3.0 release
OK, I think all the binding votes are for adopting JDK 1.5 with the
following plan:
1. Put in any new deprecations we want, cleanups, etc.
2. Release 2.4 so all of Mike M's goodness is available to 1.4 users
within the next 2 months or so (no hard date) using our new release
mechanism (i.e code freeze, branch, documentation. I tentatively
volunteer to be the RM, but hope someone will be my wingman on it).
3. Announce that 2.9 will be the last version under JDK 1.4
4. Put in any other deprecations that we want and do as we did when
moving from 1.4.3 to 1.9 by laying out a migration plan, etc.
5. Release 2.9 as the last official release on JDK 1.4
6. Switch 3.0-dev to be on JDK 1.5, removing any deprecated code and
updating ANT to use 1.5 for source and target.
7. Start accepting JDK 1.5 patches on 3.0-dev
I am going to put this up on the Wiki as well. We can open JIRA
issues as appropriate. I would think it is reasonable to assume we
will be on 1.5 by the end of the year, right, since 2.9 will be a
housekeeping release, more or less?
Cheers,
Grant
On Jul 30, 2007, at 12:48 PM, Grant Ingersoll wrote:
>
> On Jul 30, 2007, at 8:18 AM, DM Smith wrote:
>
>> +1 from me, too. Not because I have a vote or that I am for going
>> to 1.5, but because it is inevitable and this is a well thought
>> out, fine plan. (excepting the aggressive timeline that has been
>> hashed out already in this thread)
>>
>> I'd like to point out that there is a consequence of this plan and
>> how Lucene has done things in the past.
>>
>> At 1.9 it was fully compatible with 1.4.3, with deprecations. 2.0
>> mostly had deprecations removed and a few bug fixes. Then the 2.x
>> series has been backwardly compatible but not with 1.x (except
>> being able to read prior indexes, perhaps a few other things.).
>>
>> If we continue that same pattern, then there will be no 1.5
>> features in 2.9. (Otherwise it won't compile under 1.4). Thus, 3.0
>> will have a 1.4.2 compatible interface. And except for new
>> classes, new methods and compile equivalent features (such as
>> Enums), 1.5 features won't appear in the 3.x series API.
>>
>
> Yes, this is a slight variation from the 1.9 -> 2.0 migration. I
> think the plan is to switch to 1.5 for compilation for 3.0-dev and
> then we will be immediately open for accepting 1.5 patches. In
> fact, if someone submitted a patch that converted all collections
> to generics, I would be in favor of accepting it with all the usual
> caveats. I don't see any other way around, as I don't think the
> intent is to say that 3.x contains no 1.5 features other than it
> compiles using JDK 1.5.
>
>
>> I think it is very important to preserve the Lucene API where
>> possible and reasonable, not changing it without gain. Given that
>> this has been the practice, I don't think it is an issue.
>>
>
> I agree. I think method names, etc. will stay the same, but we
> will start adding Generics and Enums where appropriate and new code
> can be all 1.5. For instance, though, the Field declaration
> parameters are a prime place for Enums. So, the move would be to
> add in the new Enums and deprecate the old Field.Index and
> Field.Store static ints. Thus, they would not go away until 4.x
> (wow, that is weird to say)
>
> Does that seem reasonable?
>
> -Grant
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
------------------------------------------------------
Grant Ingersoll
http://www.grantingersoll.com/
http://lucene.grantingersoll.com
http://www.paperoftheweek.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
Re: [VOTE] Migrate Lucene to JDK 1.5 for 3.0 release
Posted by Grant Ingersoll <gr...@gmail.com>.
yes. 2.3 then on to 2.9
On Aug 2, 2007, at 11:02 AM, Steven Parkes wrote:
> Hmmmm ... just a nit (or did I miss something?) in (2), do you mean
> 2.3?
>
>
> -----Original Message-----
> From: Grant Ingersoll [mailto:grant.ingersoll@gmail.com]
> Sent: Thursday, August 02, 2007 5:29 AM
> To: java-dev@lucene.apache.org
> Subject: Re: [VOTE] Migrate Lucene to JDK 1.5 for 3.0 release
>
> OK, I think all the binding votes are for adopting JDK 1.5 with the
> following plan:
> 1. Put in any new deprecations we want, cleanups, etc.
> 2. Release 2.4 so all of Mike M's goodness is available to 1.4 users
> within the next 2 months or so (no hard date) using our new release
> mechanism (i.e code freeze, branch, documentation. I tentatively
> volunteer to be the RM, but hope someone will be my wingman on it).
> 3. Announce that 2.9 will be the last version under JDK 1.4
> 4. Put in any other deprecations that we want and do as we did when
> moving from 1.4.3 to 1.9 by laying out a migration plan, etc.
> 5. Release 2.9 as the last official release on JDK 1.4
> 6. Switch 3.0-dev to be on JDK 1.5, removing any deprecated code and
> updating ANT to use 1.5 for source and target.
> 7. Start accepting JDK 1.5 patches on 3.0-dev
>
>
> I am going to put this up on the Wiki as well. We can open JIRA
> issues as appropriate. I would think it is reasonable to assume we
> will be on 1.5 by the end of the year, right, since 2.9 will be a
> housekeeping release, more or less?
>
> Cheers,
> Grant
>
> On Jul 30, 2007, at 12:48 PM, Grant Ingersoll wrote:
>
>>
>> On Jul 30, 2007, at 8:18 AM, DM Smith wrote:
>>
>>> +1 from me, too. Not because I have a vote or that I am for going
>>> to 1.5, but because it is inevitable and this is a well thought
>>> out, fine plan. (excepting the aggressive timeline that has been
>>> hashed out already in this thread)
>>>
>>> I'd like to point out that there is a consequence of this plan and
>>> how Lucene has done things in the past.
>>>
>>> At 1.9 it was fully compatible with 1.4.3, with deprecations. 2.0
>>> mostly had deprecations removed and a few bug fixes. Then the 2.x
>>> series has been backwardly compatible but not with 1.x (except
>>> being able to read prior indexes, perhaps a few other things.).
>>>
>>> If we continue that same pattern, then there will be no 1.5
>>> features in 2.9. (Otherwise it won't compile under 1.4). Thus, 3.0
>>> will have a 1.4.2 compatible interface. And except for new
>>> classes, new methods and compile equivalent features (such as
>>> Enums), 1.5 features won't appear in the 3.x series API.
>>>
>>
>> Yes, this is a slight variation from the 1.9 -> 2.0 migration. I
>> think the plan is to switch to 1.5 for compilation for 3.0-dev and
>> then we will be immediately open for accepting 1.5 patches. In
>> fact, if someone submitted a patch that converted all collections
>> to generics, I would be in favor of accepting it with all the usual
>> caveats. I don't see any other way around, as I don't think the
>> intent is to say that 3.x contains no 1.5 features other than it
>> compiles using JDK 1.5.
>>
>>
>>> I think it is very important to preserve the Lucene API where
>>> possible and reasonable, not changing it without gain. Given that
>>> this has been the practice, I don't think it is an issue.
>>>
>>
>> I agree. I think method names, etc. will stay the same, but we
>> will start adding Generics and Enums where appropriate and new code
>> can be all 1.5. For instance, though, the Field declaration
>> parameters are a prime place for Enums. So, the move would be to
>> add in the new Enums and deprecate the old Field.Index and
>> Field.Store static ints. Thus, they would not go away until 4.x
>> (wow, that is weird to say)
>>
>> Does that seem reasonable?
>>
>> -Grant
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>
>
> ------------------------------------------------------
> Grant Ingersoll
> http://www.grantingersoll.com/
> http://lucene.grantingersoll.com
> http://www.paperoftheweek.com/
>
>
>
> ---------------------------------------------------------------------
> 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
>
------------------------------------------------------
Grant Ingersoll
http://www.grantingersoll.com/
http://lucene.grantingersoll.com
http://www.paperoftheweek.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
RE: [VOTE] Migrate Lucene to JDK 1.5 for 3.0 release
Posted by Steven Parkes <st...@esseff.org>.
Hmmmm ... just a nit (or did I miss something?) in (2), do you mean 2.3?
-----Original Message-----
From: Grant Ingersoll [mailto:grant.ingersoll@gmail.com]
Sent: Thursday, August 02, 2007 5:29 AM
To: java-dev@lucene.apache.org
Subject: Re: [VOTE] Migrate Lucene to JDK 1.5 for 3.0 release
OK, I think all the binding votes are for adopting JDK 1.5 with the
following plan:
1. Put in any new deprecations we want, cleanups, etc.
2. Release 2.4 so all of Mike M's goodness is available to 1.4 users
within the next 2 months or so (no hard date) using our new release
mechanism (i.e code freeze, branch, documentation. I tentatively
volunteer to be the RM, but hope someone will be my wingman on it).
3. Announce that 2.9 will be the last version under JDK 1.4
4. Put in any other deprecations that we want and do as we did when
moving from 1.4.3 to 1.9 by laying out a migration plan, etc.
5. Release 2.9 as the last official release on JDK 1.4
6. Switch 3.0-dev to be on JDK 1.5, removing any deprecated code and
updating ANT to use 1.5 for source and target.
7. Start accepting JDK 1.5 patches on 3.0-dev
I am going to put this up on the Wiki as well. We can open JIRA
issues as appropriate. I would think it is reasonable to assume we
will be on 1.5 by the end of the year, right, since 2.9 will be a
housekeeping release, more or less?
Cheers,
Grant
On Jul 30, 2007, at 12:48 PM, Grant Ingersoll wrote:
>
> On Jul 30, 2007, at 8:18 AM, DM Smith wrote:
>
>> +1 from me, too. Not because I have a vote or that I am for going
>> to 1.5, but because it is inevitable and this is a well thought
>> out, fine plan. (excepting the aggressive timeline that has been
>> hashed out already in this thread)
>>
>> I'd like to point out that there is a consequence of this plan and
>> how Lucene has done things in the past.
>>
>> At 1.9 it was fully compatible with 1.4.3, with deprecations. 2.0
>> mostly had deprecations removed and a few bug fixes. Then the 2.x
>> series has been backwardly compatible but not with 1.x (except
>> being able to read prior indexes, perhaps a few other things.).
>>
>> If we continue that same pattern, then there will be no 1.5
>> features in 2.9. (Otherwise it won't compile under 1.4). Thus, 3.0
>> will have a 1.4.2 compatible interface. And except for new
>> classes, new methods and compile equivalent features (such as
>> Enums), 1.5 features won't appear in the 3.x series API.
>>
>
> Yes, this is a slight variation from the 1.9 -> 2.0 migration. I
> think the plan is to switch to 1.5 for compilation for 3.0-dev and
> then we will be immediately open for accepting 1.5 patches. In
> fact, if someone submitted a patch that converted all collections
> to generics, I would be in favor of accepting it with all the usual
> caveats. I don't see any other way around, as I don't think the
> intent is to say that 3.x contains no 1.5 features other than it
> compiles using JDK 1.5.
>
>
>> I think it is very important to preserve the Lucene API where
>> possible and reasonable, not changing it without gain. Given that
>> this has been the practice, I don't think it is an issue.
>>
>
> I agree. I think method names, etc. will stay the same, but we
> will start adding Generics and Enums where appropriate and new code
> can be all 1.5. For instance, though, the Field declaration
> parameters are a prime place for Enums. So, the move would be to
> add in the new Enums and deprecate the old Field.Index and
> Field.Store static ints. Thus, they would not go away until 4.x
> (wow, that is weird to say)
>
> Does that seem reasonable?
>
> -Grant
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
------------------------------------------------------
Grant Ingersoll
http://www.grantingersoll.com/
http://lucene.grantingersoll.com
http://www.paperoftheweek.com/
---------------------------------------------------------------------
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