On Tue, 2019-11-26 at 20:56 +0100, Michael Osipov wrote: > Am 2019-11-26 um 20:51 schrieb Oleg Kalnichevski: > > On Tue, 2019-11-26 at 20:31 +0100, Michael Osipov wrote: > > > Am 2019-11-26 um 20:13 schrieb Oleg Kalnichevski: > > > > On Tue, 2019-11-26 at 19:08 +0100, Michael Osipov wrote: > > > > > Am 2019-11-26 um 16:41 schrieb Oleg Kalnichevski: > > > > > > Folks > > > > > > > > > > > > I would like to create new 4.5.x branch in HttpCore and do > > > > > > the > > > > > > following > > > > > > > > > > > > * change its version to 4.5.0-alpha1 > > > > > > > > > > > > * change its JRE level from 1.6 to 1.7 > > > > > > > > > > > > * back-port new connection pool implementations from master > > > > > > to > > > > > > that > > > > > > branch > > > > > > > > > > > > * deprecate old connection pool implementations > > > > > > > > > > > > Would anyone have any objections to that? > > > > > > > > > > > > Obviously all new features would need to the 4.5.x branch > > > > > > and > > > > > > not > > > > > > 4.4.x. The 4.4.x would be for critical bug fixes only. > > > > > > > > > > I don't understand why you want to do that? Do you want to > > > > > evolve > > > > > the > > > > > 4.x branch in parallel to master like Tomcat does? I thought > > > > > 5.0 > > > > > is > > > > > a > > > > > successor to the 4.x line. > > > > > > > > > > > > > Realistically we cannot deprecate and stop supporting the 4.x > > > > code > > > > line > > > > the same moment 5.0 goes GA. We will have to support both 4.x > > > > and > > > > 5.x > > > > for quite some time. > > > > > > Yes, I see. That makes sense. We should also agree how long the > > > 4.x > > > is > > > going to be supported and how the support will look like. Fixes > > > only, > > > or > > > backports too. > > > > > > > Recently the old connection pooling code in HttpAsyncClient has > > > > been > > > > giving me quite some grief. Ideally I would like to be able to > > > > replace > > > > it with something known to be better instead of having to patch > > > > the > > > > old > > > > implementation all the time. > > > > > > Is Commons Pool an option? Or even the high-performance Tomcat > > > JDBC > > > Pool > > > stripped for the JDBC part? It is little code compared to Commons > > > Pool. > > > > > > > It is an option but what would exactly be the upside? On the > > downside > > we would likely lose the ability to support stateful connections > > that > > we presently have in 4.x and 5.x. > > Upside: we use well tested, existing ASF code. >
Are you sure? Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
