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.
>
>> 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.
>
>
>> 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? Or we just drop
support for 1.5?
>> 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 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. That means we minimally would have to support both of those. That
means porting patches, answering bug reports, etc.
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).
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?
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
