commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simonetrip...@apache.org>
Subject Re: [POOL2][PROPOSAL] releasing commons-pool2-2.0-beta1
Date Thu, 05 May 2011 19:27:22 GMT
Hi all,
looks like I've been causing too much flares! :D

I understand your concerns, anyway, as in the subject, I just proposed
a *2.0-beta1* release, as a first - of many, maybe - intermediate step
before pushing the 2.0.
We could even downgrade it to alpha1, and warning users that APIs can
appears/disappear without any warning.
At the end of the day I don't want to hurry anybody, my intention was
just a proposal! :)

Have a nice day!!!
Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Thu, May 5, 2011 at 8:24 PM, Phil Steitz <phil.steitz@gmail.com> wrote:
> On 5/5/11 10:12 AM, Gary Gregory wrote:
>> On Thu, May 5, 2011 at 12:33 PM, Phil Steitz <phil.steitz@gmail.com> wrote:
>>
>>> On 5/5/11 9:20 AM, Gary Gregory wrote:
>>>> I would like to propose an aggressive release schedule:
>>>>
>>>> - Push 2.0 out as a generified version of 1.5 ASAP and add/remove/fiddle
>>>> nothing else. "Just give me the generics P L E A S E!" :) Change
>>> deprecated
>>>> documentation from "Will be removed in 2.0" to "Will be removed in 3.0".
>>> Why such a rush to just get generics?
>>>
>> It's been forever and I'm tired of looking type casts and other hacks. Why
>> NOT is the better question. It's there, it's done, let's take a look at it.
>> Thank you Simone BTW.
>>
>>
>>> Honestly, this makes no sense
>>> to me.  If you really want a type-safe pool, it is easy enough to
>>> wrap the methods that borrow and return objects.
>>
>> It makes a lot of sense to me to bullet proof pool call sites using
>> generics.
>>
>> It makes even more sense to me to do it with a small step instead of a big
>> one using a next gen pool release that may break apps in subtle ways.
>>
>> I have some subclassing/wrapping/hacking/blech already. It seems like you're
>> suggesting that folks go off and create throw away work . That does not sit
>> well with me when I know that enabling generics on top on 1.5 is done and it
>> ready for review. It's easy and makes your life easier.
>>
>>
>>> If we make this
>>> decision, we are effectively deciding that the current pool API is
>>> going to be *the* API for several years to come.
>>
>> But so what? It'll be supported as long as folks like us volunteer to do it
>> for any given release.
>
> That's the problem.  We have frankly collectively had a terrible
> track record keeping up with pool and dbcp bugs.  I take
> accountability for that since I have been cutting the releases.
> These components are widely reused and prone to difficult bugs and
> small changes can lead to disasters for production systems.  I don't
> personally have the bandwidth to birth and maintain yet another
> version of [pool] and there has not been sufficient help available
> resolving the real bugs in prior releases to make it a wise decision
> for the Commons PMC to release another version at this time.   What
> I can volunteer to help with is developing a 2.0 version that we can
> stand behind.  We don't have that yet.
>
>> I say: Here is 2.0 (or 1.6 if we want to call it
>> that): It's 1.5 with generics, enjoy! :) Next up, for 2.0/3.0, we're doing
>> this and that, which are bigger changes with more serious implications. Keep
>> the ball moving I say. Why wait for Big Bang releases?
>>
>>
> Because we have made incompatible changes in the API.  That can only
> happen in major releases.  These need to be planned and executed
> carefully.  Once we fix the 2.0 API, we can move quiclky through
> 2.1, 2.2, etc., as long as we have volunteers to help develop and
> maintain the code.  Major releases take more time to get right.
> That is natural and we have learned - repeatedly - that rushing to
> push a major release out before the API is ready is a bad idea for
> both us and users.
>
>>> We may also be
>>> painting ourselves into a performance corner supporting all of the
>>> features in the current API.
>>>
>> We won't know that until we really get
>>> the DBCP integration and performance testing done.
>>>
>> OK, we may... or we may not. I have no idea. I'm a DBCP user too but I don't
>> want to wait for some complex release train (a la Eclipse).
>
> I am also a DBCP user and the last thing I want is a release that
> kills performance and/or introduces nasty bugs - both of which can
> be / have been the product of bad [pool] releases.
>
> Phil
>> Gary
>>
>>
>>> Phil
>>>
>>>> - Next is 3.0: This is what we had meant 2.0 to be. Do all the other
>>> clean
>>>> ups, re-architecting, fiddling, removing of deprecation, refactoring, and
>>> so
>>>> on.
>>>>
>>>> Gary
>>>>
>>>> On Thu, May 5, 2011 at 11:54 AM, Simone Tripodi <
>>> simonetripodi@apache.org>wrote:
>>>>> Hi all guys,
>>>>> some of us (me included :P) are waiting for pool with generics; now
>>>>> that the migration has been done, WDYT about releasing a beta1
>>>>> release?
>>>>> It is basically the latest pool-1.5.X API, but with generics, at least
>>>>> we can start playing with it.
>>>>> Thoughts? Just let me know, I can take care of it!
>>>>> Have a nice day,
>>>>> Simo
>>>>>
>>>>> http://people.apache.org/~simonetripodi/
>>>>> http://www.99soft.org/
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

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


Mime
View raw message