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.ste...@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.ste...@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 < >>> simonetrip...@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-unsubscr...@commons.apache.org >>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>> >>>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
