On Fri, Dec 23, 2011 at 2:29 PM, Mark Thomas <ma...@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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- http://www.grobmeier.de https://www.timeandbill.de --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
