lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andi Vajda <va...@osafoundation.org>
Subject Re: Finishing Lucene 2.9
Date Tue, 25 Aug 2009 16:11:44 GMT

On Sun, 23 Aug 2009, Mark Miller wrote:

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

Sure, as long as they don't go against the "fast turnaround" goal.

As for version number, I think that the pending release number should be 2.9 
(as in 3.0 with lots of back compat and 1.4 baggage), and the next one be 
3.0, following shortly (say, three weeks later) after 2.9.

As for backwards compatility, I think there should be a blanket amnesty on 
backwards compatibility breaks for 2.9 - 3.0 - 3.0.x,y,z - 3.1 so that the 
APIs can be made sane, consistent and free of back compat compromises. It is 
difficult to get all of this right in one release, for sure. Exposing faster 
releases to more users and setting expectations accordingly would be a win 
for the next few releases, I think.

Just my $0.02...

Andi..

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

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