commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Grobmeier <grobme...@gmail.com>
Subject Re: [pool] [POOL-208] Support Java 1.5 Generics in version 1.x.
Date Fri, 23 Dec 2011 11:33:40 GMT
On Wed, Dec 21, 2011 at 7:31 PM, Phil Steitz <phil.steitz@gmail.com> wrote:
> On 12/21/11 11:09 AM, Gary Gregory wrote:
>> On Wed, Dec 21, 2011 at 1:03 PM, Mark Thomas <markt@apache.org> wrote:
>>
>>> On 21/12/2011 16:57, Phil Steitz wrote:
>>>> On 12/21/11 9:41 AM, Christian Grobmeier wrote:
>>>>> On Wed, Dec 21, 2011 at 5:19 PM, Phil Steitz <phil.steitz@gmail.com>
>>> wrote:
>>>>>> 1.5.x ships with tomcat and is used by lots of other production
>>>>>> applications.  We need to maintain the ability to patch it.
>>>>> Tomcat 5.5 (the oldest stable version i can find) uses Java 5:
>>>>> http://tomcat.apache.org/tomcat-5.5-doc/setup.html
>>>>>
>>>>> This proposed release is binary compatible - they should not have any
>>>>> issue to upgrade, right?
>>>>> How long would you like to maintain the elder 1.5.x code without java
5
>>> support?
>>>> At least until 2.0 is out and for some time after that.  Asking
>>>> tomcat and others to upgrade twice makes no sense.  I will let Mark
>>>> or other tc committers comment on that.
>>> Tomcat will continue to use 1.5.x since that is what DBCP uses. When
>>> 2.0.x is ready, trunk will switch to 2.0.x and the associated DBCP
>>> release. Depending on the results, the release branches (5.5.x, 6.0.x
>>> and 7.0.x) may follow.
>>>
>>> Tomcat is highly unlikely to use Pool 1.6.x
>>>
>> Which is quite fine with me.
>>
>> My goal is only to provide a version of pool-1 with generics that is as
>> least disruptive as possible.
>
> That is great for your own use, but what releasing it does is sets
> us up to support 3 versions.  We are having a hard enough time just
> supporting one.  When we release 2.0, we will have two release
> branches to maintain.  The 1.5.x code itself is fairly stable, but
> 1.5 was pretty much a complete rewrite of the core code and I expect
> we will continue to get bug reports against this code.  Maintaining
> two versions of it does not sound fun to me and I really think it is
> unwise to set ourselves up to try to do it.

OK, sorry if I ask the same question in the same dumb way all the
time... but we have figured out 1.5 will be binary compatible with
1.6.
We can't we then simply drop 1.5 and go forward with 1.6?

So far i have see the reason: Tomcat 5.5 runs with jdk1.4.2. Is this
actually the reason we don't go forward? Because another project needs
the 1.5 series?
If this is the case, then the EOL of Tomcat 5.5 is the earliest EOL of Pool 1.5.

This does mean pool can earliest go forward in September 2012:
http://tomcat.apache.org/tomcat-55-eol.html

Just want to know. I ask this because I start to believe we should
introduce EOL dates for our components.

On 1.6, question is if this series will be so time consuming as
expected. After all, 1.5 dev is at a minimum as understood it. It
should be easy for Gary to move the changes to 1.6 version, if he is
willing to care on that (nasty tongues tell me Git would help in this
case).

If 1.6 is coming and this project does not support it, how can we
handle it? After all we are not working for the Tomcat project, we are
working for ourselves, and Gary needs a generic version. I would not
like to see him going and make up a github fork. People outside of
this project are already saying we are like dinosaurs (collections vs
guava). We should probably discuss how we can do this - probably Gary
could make some kind of "half official" release, a bit of an
"experimental" tagged one. One people do not rely upon, except they
know what they are doing. Probably a 1.5-extended version, like in
Lord of the Rings.

Cheers
Christian

-- 
http://www.grobmeier.de
https://www.timeandbill.de

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


Mime
View raw message