Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Received-SPF: pass (nike.apache.org: domain of markrmiller@gmail.com
 designates 74.125.92.26 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:x-enigmail-version:content-type
         :content-transfer-encoding;
        b=uCzUS5vsomo5ZmdAfvKOa376petj4ShK+AMKnrrmcWoxwcGcZ2aT0vn7IZBDhur5ti
         eExP4kwEMySEqddf/wVqpMfgFeNAtoWV/UfFUCeX5+PbiCqGmVpxmDmkGHoMkENmN/bV
         8ARGNGRi60NFx/eenvd5FnqyjZn2EfvLCCIHg=
Message-ID: <4A8E0026.2070101@gmail.com>
Date: Thu, 20 Aug 2009 22:02:14 -0400
From: Mark Miller <markrmiller@gmail.com>
User-Agent: Thunderbird 2.0.0.22 (X11/20090804)
MIME-Version: 1.0
To: java-dev@lucene.apache.org
Subject: Re: Finishing Lucene 2.9
References: <4A89DF01.8060204@gmail.com>
 <023747052468446192CBC180E340FB74@VEGA> <4A8B0053.4030104@gmail.com>
 <9ac0c6aa0908181228o2c1cda63l2f77a09959c34a69@mail.gmail.com>
 <4A8C10FB.4030108@gmail.com> <596D2C98A44141778B23462582A1BE6E@VEGA>
 <4A8C7AE5.5040409@gmail.com>
 <9ac0c6aa0908200308o27e6a63atcf57188d5e6bc4af@mail.gmail.com>
 <4A8D485A.2010106@gmail.com>
 <786fde50908200605t527f56d5tf79f4e6b32f03ea8@mail.gmail.com>
 <648D9A4E4F1F418DB23BF94D14F1EA11@VEGA>
 <3AA449F0-5957-4DFA-B050-923D92424206@apache.org>
 <4A8DFFB7.2080001@gmail.com>
In-Reply-To: <4A8DFFB7.2080001@gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit

I guess you could consider that you have to use 1.5 the break?

But I think that goes without saying ...

Mark Miller wrote:
> bq.  While technically it breaks back compatibility,
>
> How does it break back compatibility? Generics are only compile time -
> they simply don't exist in the binary. Java itself is extremely back
> compat, so you can still use StringBuffer and the rest. I didn't find
> anything in the archives or the wiki that talks about a back compat
> break - that I can find anyway ...
>
>
> Grant Ingersoll wrote:
>   
>> Please read the archives on the 1.5 move.  We have discussed it many
>> times.  There is also a Wiki page on it under the committers section.
>>  While technically it breaks back compatibility, we are going forward
>> with it and we decided to allow generics, etc. right from the start.
>>  We also didn't feel like we had to convert everything in one fell
>> swoop, either, as that will break many existing patches.  
>>
>>
>> On Aug 20, 2009, at 4:29 PM, Uwe Schindler wrote:
>>
>>     
>>> It would **not** break apps without generics, if the �upper� type is
>>> the same (which is easily fulfilled by my example with the
>>> AttributeSource). The whole 1.5 Java Collection API uses generics and
>>> 1.4 programs still run.
>>>  
>>>
>>> -----
>>> Uwe Schindler
>>> H.-H.-Meier-Allee 63, D-28213 Bremen
>>> http://www.thetaphi.de
>>> eMail: uwe@thetaphi.de <mailto:uwe@thetaphi.de>
>>>
>>> ------------------------------------------------------------------------
>>> *From:* Shai Erera [mailto:serera@gmail.com] 
>>> *Sent:* Thursday, August 20, 2009 3:05 PM
>>> *To:* java-dev@lucene.apache.org <mailto:java-dev@lucene.apache.org>
>>> *Subject:* Re: Finishing Lucene 2.9
>>>  
>>>
>>> What will be w/ generics? Won't they break cack-compat as soon as we
>>> add them (e.g., if we move to accepting parameters as generics - it
>>> may break an application which does not use generics yet). I think
>>> that the move to 1.5 needs to include the generics as well, unless
>>> we're willing to break back-compat later on.
>>>
>>> Shai
>>>
>>> On Thu, Aug 20, 2009 at 3:58 PM, Mark Miller <markrmiller@gmail.com
>>> <mailto:markrmiller@gmail.com>> wrote:
>>>
>>> Michael McCandless wrote:
>>>       
>>>> On Wed, Aug 19, 2009 at 6:21 PM, Mark Miller<markrmiller@gmail.com
>>>>         
>>> <mailto:markrmiller@gmail.com>> wrote:
>>>       
>>>>         
>>>>> I forgot about this oddity. Its so weird. Its like we are doing two
>>>>> releases on top of each other - it just seems confusing.
>>>>>
>>>>>           
>>>> I'm also not wed to the "fast turnaround" (remove deprecations, switch
>>>> to generics) 3.0 release.
>>>>
>>>> We could, instead, take out time doing the 3.0 release, ie let it
>>>> include new features too.
>>>>
>>>> I thought I had read a motivation for the 1.9 -> 2.0 fast turnaround,
>>>> but I can't remember it nor find it now...
>>>>
>>>> Mike
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>>>>         
>>> <mailto:java-dev-unsubscribe@lucene.apache.org>
>>>       
>>>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>>>         
>>> <mailto:java-dev-help@lucene.apache.org>
>>>       
>>>>         
>>> I thought the motivation was to provide a clean upgrade path with the
>>> deprecations - you move to 2.9 and move from all the deprecated methods
>>> - then you move to 3.0 and your good with no deprecations. I'd guess the
>>> worry is that new features in 3.0 would add new deprecations and its not
>>> quite so clean?
>>>
>>> Personally, I think thats fine though. New deprecations will come in 3.1
>>> anyway. You can still move everything in 2.9, and then move to 3.0 - so
>>> what if something else is now deprecated? You can move again or wait for
>>> 3.9 to move ...
>>>
>>> --
>>> - Mark
>>>
>>> http://www.lucidimagination.com
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>>> <mailto:java-dev-unsubscribe@lucene.apache.org>
>>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>> <mailto:java-dev-help@lucene.apache.org>
>>>
>>>  
>>>       
>> --------------------------
>> Grant Ingersoll
>> http://www.lucidimagination.com/
>>
>> Search the Lucene ecosystem (Lucene/Solr/Nutch/Mahout/Tika/Droids)
>> using Solr/Lucene:
>> http://www.lucidimagination.com/search
>>
>>     
>
>
>   


-- 
- Mark

http://www.lucidimagination.com


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org