lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Miller <markrmil...@gmail.com>
Subject Re: Finishing Lucene 2.9
Date Sun, 23 Aug 2009 17:37:27 GMT
I'm still +1 on calling this 3.0 as I was before when you mentioned it.
Its a wakeup call that the upgrade is a bit major in certain areas.

In either case - 3.0 is more representative of what this release is IMO.

I also think we should allow new features in 3.0 if we release this as 2.9.

- Mark


Michael McCandless wrote:
> Right, this (you can jump to 2.9, fix all deprecations, then easily
> move to 3.0 and see no deprecations) is my understanding too, but I
> don't see what's particularly useful about that.  It does produce a
> Lucene release that has zero deprecated APIs (assuming we remove all
> of them), but I don't think that's very important.  Also, it's extra work
> having to do a "no-op, except for deprecations removal and generics
> addition" release :)
>
> Vs say taking our time creating 3.0, letting it have real features,
> etc.
>
> Or, another option would be to simply release 3.0 next.  After all,
> there are some seriously major changes in this release, compilation
> breakage, etc. ... things you'd more expect (of "traditional"
> software) in a .0 release.  And, then state clearly that all
> deprecated APIs in 3.0 will be removed in 3.1.  While this is
> technically a change to our back-compat policy, it's also just a
> number-shifting game since it would just be a rename
> (2.9 becomes 3.0; 3.0 becomes 3.1).
>
> Mike
>
> On Thu, Aug 20, 2009 at 8:58 AM, Mark Miller<markrmiller@gmail.com> wrote:
>   
>> Michael McCandless wrote:
>>     
>>> On Wed, Aug 19, 2009 at 6:21 PM, Mark Miller<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
>>> For additional commands, e-mail: 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
>> 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
>
>   


-- 
- 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


Mime
View raw message