Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: domain of billwbarker@verizon.net
 designates 206.46.173.5 as permitted sender)
Message-id: <401BCA722D1045DEB454C4B5BC09522F@BillPC>
From: "Bill Barker" <billwbarker@verizon.net>
To: "Commons Developers List" <dev@commons.apache.org>
References: 
 <CACZkXPz3OHgGy6ZVJeexOhSx_gaY3dG5R1o6T08zzVCJA6xfpQ@mail.gmail.com>
 <4EF20068.5070200@gmail.com>	<-209817214533913095@unknownmsgid>
 <4EF2072E.7050403@gmail.com>
 <CAPFNckh4MCD2DYG6cRkJHgz1JDXdTxQRizD43VFoudECpHpC_w@mail.gmail.com>
 <4EF21008.4020207@gmail.com>	<4EF21F8E.5010204@apache.org>
 <CACZkXPyF82A5-AZaWYLh-sFc0_Ld63hdgcFjANMAyr0YzYo7dA@mail.gmail.com>
 <4EF2261F.1050507@gmail.com>
 <CAPFNckgSwCLd4phhiqcbN7L-g-9Vp7LdCPEUC7fyxyGEqjGF1Q@mail.gmail.com>
 <CABzHfVkDUPvntht5NJU6R-tyKLNa+KYyOnR2bFG0RSs8V65AXg@mail.gmail.com>
In-reply-to: 
 <CABzHfVkDUPvntht5NJU6R-tyKLNa+KYyOnR2bFG0RSs8V65AXg@mail.gmail.com>
Subject: Re: [pool] [POOL-208] Support Java 1.5 Generics in version 1.x.
Date: Sun, 25 Dec 2011 15:50:54 -0800
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=iso-8859-1;
 reply-type=original
Content-transfer-encoding: 7bit
Importance: Normal


-----Original Message----- 
From: Konstantin Kolinko
Sent: Sunday, December 25, 2011 1:15 AM
To: Commons Developers List
Subject: Re: [pool] [POOL-208] Support Java 1.5 Generics in version 1.x.

2011/12/23 Christian Grobmeier <grobmeier@gmail.com>:
> 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.
>
>
>I think Tomcat 5.5 can go with latest released version of pool 1.5,
>taking it from archives.
>
>TC 5.5 is currently configured to use pool 1.5.5 (as opposed to later
>1.5.6 or 1.5.7) [1], and I am not going to propose upgrade of that,
>though other Tomcat committers can propose it.
>
>The only question might be if there are some critical bug fixes (and I
>think you will be able to backport those).
>
>Also I wonder what changes are required in Gump configuration.
>
>[1] 
>http://svn.apache.org/viewvc/tomcat/tc5.5.x/trunk/build/build.properties.default?view=markup#l178
>

There isn't any change needed for Gump since TC 5.5 doesn't run tests there 
and doesn't have a compile time dependency on [pool].

>
> 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.
>

Best regards,
Konstantin Kolinko

---------------------------------------------------------------------
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