On Tue, Dec 13, 2011 at 10:44 AM, Phil Steitz <phil.ste...@gmail.com> wrote:
> > > > > On Dec 13, 2011, at 7:10 AM, Gary Gregory <garydgreg...@gmail.com> wrote: > > > On Tue, Dec 13, 2011 at 8:22 AM, Phil Steitz <phil.ste...@gmail.com> > wrote: > > > >> Lots of applications depend on the 1.x branch as it is now. > > > > > > Hello, > > > > What does it mean for an app to depend on a specific branch in SVN? > > > > Do those apps depend on 1.x SNAPSHOT releases? Do they download the code > > and compile it? Which is where moving to J1.5 be a problem? How can such > a > > thing even be supported? > > Many production apps (including tomcat and several other ASF projects) > depend on the released versions of pool and or DBCP. > So? Like you said, they depend on "released versions", no one is going to go to those apps a change their jars. > > > > >> We really can't just drop support. > > > > > > I am not asking to drop support. Anyone one can do as they please to > > support whatever version they want. If I want to stay on J1.3 and fix the > > P1.5.x line, I can do so. > > > Generics is the natural evolution of the P1.x line from P1.5 to a P1.6. > I'm > > not interested in J1.3, so I'm not going to support it. I am interested > in > > generics now, so I am supporting it now. If there were no P1.6, then yes, > > I'd fix P1.5 because that would be the only game in town. > > But there is 2.0, which we should move forward with. > Great, I'll test it when it is ready. Until then it's easier to drop in a binary compatible 1.6. > > > > > >> At least we shouldnt, IMO. What you are proposing is a third release > >> line. > > > > > > There is no need for a third release line until someone needs it and does > > the work. If I am stuck on pre-J1.5 and I want a 1.5.x, I create that > > release, if that means I have to create a branch, then that's what I have > > to do to support an obsolete J1.3 platform. > > So you are recommending that we cut a 1.6 and not support it? That would be silly. > Or we just drop support for 1.5? > IMO, 1.5 is just as 'supported' as [lang2]: nothing stops me from a cutting a 2.x release to fix a bug. > > > >> As I have stated before, we are having a hard time getting timely bug > fix > >> releases out now with just *one* release line. Are you prepared to > >> support the code fully? Are there other volunteers willing to step up to > >> diagnose and fix bugs in two versions of the 1.x branch? > >> > > > > Right now, I'm doing the best I can do for [pool1] and generics. I'll > > support the code the same way I support any Commons code, when I take the > > time to do so. If P1.6 is as simple as /only/ adding generics, then I > > predict we'll see a good adoption rate. > > > Effectively killing 2.0. If [pool2] is not better than [pool1+generics] then that is a different problem. From what I've read, it feels like pool1 has other problems to justify pool2. > If that is what we want to do, then we can go that way. What I don't > think we can responsibly sign up for is supporting 1.5, 1.6 and 2. Forcing > everyone to upgrade from 1.5 to 1.6 immediately is not realistic. I don't get it. Who is forcing anyone to upgrade? Is there some mysterious force in the universe that compels developers to upgrade their builds blindly? First, someone says: we can't upgrade anything because the world depends on us, then, that's followed up by: everyone else is automatically, uncontrollably and forcibly upgrading their apps. I don't live in that bizarro world. For example, at work, our policy is grant a component upgrade if it is backed some measurable business value, like a bug fix that affects a customer. In the case of generics, the benefit is maintenance, avoid coding new bugs, and binary compatibility. > That means we minimally would have to support both of those. That means > porting patches, answering bug reports, etc. > Just like users are not forced to upgrade, as a volunteer here, I am not forced to burn the midnight oil. I do my best in the here and now. > The way I see it, we can realistically support at most two versions - one > "bug fix only" the other genericised and requiring incompatible change for > upgrade (note that even just adding generics will break all 1.x clients > because factories will have to be genericised). > At work, we support five versions of a large application server, with less people than exist in this community. Sure, we get paid, so that helps :) I see no need to restrict development and improvements because 'thy shall only have two versions of thy software: one of fixing, one for new work' > So the choice we have now is to drop 2.0 (which includes significant > performance enhancements and the real value of java 5 - the concurrent > package), abandon 1.5 (which is irresponsible, IMO) or forego 1.6 to get > 2.0 out. Have you tried out the 2.0 code in your apps? > You can make those choices for yourself based on your two-version reality above. I think that in our community, things that are painful get fixed, and people volunteer to do it, and do other work as well. I don't want to be shackled by some two-version system. I do not want to take the time now to test 2.0 now because it is a moving target. Witness today's commits for example. I have too much critical code that depends on pool to make a big jump to 2.0 soon, that will take some careful study of the pool2 changes. A little step for generics feels right and a lot less risky. Gary > > Phil > > I > > > > Gary > > > > > >> > >> Phil > >> > >> > >> > >> On Dec 13, 2011, at 6:11 AM, Gary Gregory <garydgreg...@gmail.com> > wrote: > >> > >>> On Tue, Dec 13, 2011 at 7:01 AM, sebb <seb...@gmail.com> wrote: > >>> > >>>> On 13 December 2011 11:36, Simone Tripodi <simonetrip...@apache.org> > >>>> wrote: > >>>>>> > >>>>>> Generics would help to ensure suitable types were being used, but> > >>>> would do nothing to prevent the subtle threading bugs that misusing a> > >>>> protected field can cause.>> To my mind, it would paper over a few > >> cracks, > >>>> whilst leaving gaping> holes elsewhere.> > >>>>> we just voted a new maintenance release for [pool] that brings > exactly > >>>>> the same bugs, what should prevent us cutting a new release adding > >>>>> something comfortable for our users - and some of us, included myself > >>>>> - such as generics? > >>>>> > >>>>>> Unfortunately, because the original code was created with exposed> > >>>> mutable data items, it's just not possible to fix it without breaking> > >>>> binary compatibility. > >>>>> > >>>>> agreed, maybe I got Gary wrong but IIUC the purpose for a 1.6 release > >>>>> is just providing Generics... or not? > >>>>> 2.0 provides a lot more - not only locks are fixed, but internals are > >>>>> more performant - so I don't see issues having 1.6 released. > >>>> > >>>> But what is the point? > >>>> > >>> > >>> The point is I really want an easy path to generics now, with as much > >>> compatibility as possible, including 1.5 warts and all. > >>> I want to clean up my [pool] call sites ASAP. It's one of the rare key > >>> spots in my app that does not support generics. > >>> We have all this nice generified code except when hitting the [pool] > >> edges, > >>> that's ugly, unsafe, and unnecessary. > >>> I also do not want the risks that come with a whole new [pool2] impl. > >>> > >>> Do generics really make enough difference to be worth spending the time > >> on? > >>>> > >>> > >>> I started this thread for a reason :) > >>> > >>> > >>>> > >>>> Note also that Pool 1.x currently targets 1.3, so adding generics will > >>>> force source compliance of at least 1.5. > >>>> > >>> > >>> Well, yes, that's not a surprise, compiling generics requires J1.5. > >>> If someone cares to maintain a Java 1.3-compliant branch, be my guest. > >>> > >>> > >>>> Not sure if it will force target compliance of 1.5 as well. If so, it > >>>> > >>> might no longer be a drop-in replacement for some isers. > >>>> > >>> > >>> True, and worse for compilation, if you do very odd things with pools, > >> your > >>> call sites might not compile. But that would be true of any new lib > that > >>> adds generics. Once you declare a pool with a type, you can't just > shove > >>> any old Object in there anymore. > >>> > >>> My proposed plan is to migrate the 1.x branch to generics (done on my > >>> machine, like Simo, it's not the first time its been done ;) > >>> > >>> If someone want to release a 1.5.x release after 1.6, create a 1.5.x > >> branch > >>> from the last 1.5.x tag. Doing another 1.5.x would mean that person > want > >>> J1.3 compatibility, and does not care for J1.5. > >>> > >>> At work, we have been on J1.6 for years and are now experimenting with > >>> J1.7. I know some people like in a pre-J1.6 world, and no one is > forcing > >>> anyone to upgrade. I do not care to rehash the 'when is it OK to use > Java > >>> 5-6' debate. > >>> > >>> As I mentioned, [pool2] can cook all it needs until it is fully baked > as > >>> far as I am concerned. If this causes people to rekindle their [pool2] > >>> efforts, then I'm happy this provided the catalyst. > >>> > >>> Gary > >>> > >>> > >>> > >>>>> My 0.02 cents, > >>>>> -Simo > >>>>> > >>>>> http://people.apache.org/~simonetripodi/ > >>>>> http://simonetripodi.livejournal.com/ > >>>>> http://twitter.com/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 > >>>> > >>>> > >>> > >>> > >>> -- > >>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > >>> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0 > >>> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK > >>> Blog: http://garygregory.wordpress.com > >>> Home: http://garygregory.com/ > >>> Tweet! http://twitter.com/GaryGregory > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> For additional commands, e-mail: dev-h...@commons.apache.org > >> > >> > > > > > > -- > > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > > JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0 > > Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK > > Blog: http://garygregory.wordpress.com > > Home: http://garygregory.com/ > > Tweet! http://twitter.com/GaryGregory > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0 Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
