commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: [pool] 1.6 proposal
Date Tue, 13 Dec 2011 16:38:42 GMT
On Tue, Dec 13, 2011 at 10:44 AM, Phil Steitz <phil.steitz@gmail.com> wrote:

>
>
>
>
> On Dec 13, 2011, at 7:10 AM, Gary Gregory <garydgregory@gmail.com> wrote:
>
> > On Tue, Dec 13, 2011 at 8:22 AM, Phil Steitz <phil.steitz@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 <garydgregory@gmail.com>
> wrote:
> >>
> >>> On Tue, Dec 13, 2011 at 7:01 AM, sebb <sebbaz@gmail.com> wrote:
> >>>
> >>>> On 13 December 2011 11:36, Simone Tripodi <simonetripodi@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-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
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >
> >
> > --
> > E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message