On Wed, Dec 21, 2011 at 7:31 PM, Phil Steitz <phil.ste...@gmail.com> wrote: > On 12/21/11 11:09 AM, Gary Gregory wrote: >> On Wed, Dec 21, 2011 at 1:03 PM, Mark Thomas <ma...@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.ste...@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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
