On Dec 23, 2011, at 6:34, Christian Grobmeier <grobme...@gmail.com> wrote:
> 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. I think components stay alive as long as we do the work to keep them alive. If I want to put in the time for [foo], then it is alive if I get votes for a release. Having an EOL makes things more constrained IMO. It sure is motivation to move on though, like in the case of JDK EOLs! :) Gary > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
