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 14:36:20 GMT
On Fri, Dec 23, 2011 at 2:29 PM, Mark Thomas <markt@apache.org> wrote:
> On 23/12/2011 11:33, Christian Grobmeier wrote:
>
>> 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
>
> Pool is already going forward in the 1.6.x branch and in 2.0.x

You and Phil are raising concerns. I try to discuss these.

>> 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).
>
> It is certainly more work but how much more is the critical question. As
> long as the code bases stay broadly similar it should be easy to patch
> 1.6.x to fix a bug and svn merge the change to 1.5.x. We do this in
> Tomcat all the time and merging from trunk (8.0.x) to 7.0.x and 6.0.x is
> generally fairly simple. Merging to 5.5.x requires more work as the
> source layout is completely different.

I have understood Gary that pool 1.6 is the same as 1.5, just with generics.

> Releases would be more work but there are folks that look to be willing
> to release 1.5.x and 1.6.x

I guess Gary is willing to serve as a RM for 1.6, I am willing to
review  the relese.

> The other bit I can think of is that the website may need some tweaks to
> handle multiple versions. I'm not familiar with the Commons web site
> generation process to judge if that is easy or hard.

I see this as an additional page in mvn site and a notice on the
toplevel website. Downloads must be tweaked.
I might be wrong.

>> 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.
>
> All that is required for a release is someone willing to tag and release
> and three PMC members to vote +1. As long as 1.5.x and 1.6.x remain
> broadly similar (i.e. 1.6.x = 1.5.x + generics) then the additional work
> of porting fixes between the two should be minimal.

This is Garys plan earlier from this thread:

"My plan is to port any fixes from 1.5.x releases to 1.6.0 if any or
encourage others to do so. I do not plan on touching 1.5.x once 1.6 is
out. Because of the binary compatibility of 1.6, I would hope that
folks would patch 1.6 first and then port to 1.5.x if asked by users,
but that's just me. I see a non-generics pool1 as a dead end. 2.0 is
great but unreleased and NOT a drop in, hence 1.6."

> We want to avoid "unofficial" releases.

Pluralis Majestatis? ;-)

> That raises all sorts of red flags at ASF board level.

I was still speaking of a release with 3x +1.

Anyway it seems your concerns are addressed.

Cheers
Christian


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



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