On 16 June 2018 at 22:41, Gary Gregory <garydgreg...@gmail.com> wrote: > Hello Mark and all, > > Thank you for the heads up on the Tomcat plans. > > Asking DBCP to stay on Java 7 for 4-5 years is insane IMO, and it certainly > is not going to attract anyone to maintain and grow this component (IMO > again.) If that is a set of handcuffs you want to live with, then by all > means ;-) > > I am sure there is nothing stopping anyone at Apache to keep patches coming > to the DBCP 2.4.x line. I plan on keeping the release train going for many > Commons component, so I am happy to release DBCP at will. > > You will notice that > https://commons.apache.org/proper/commons-dbcp/download_dbcp.cgi presents > no less than tree different versions of DBCP for different antique Java > platforms. We are just going to make that list one deeper.
I think we can now drop support for JDBC 3 and JDBC 4 (Java 6) That leaves only JDBC 4.1 (Java 7.0) as a current release. Is that really too much to continue to support? > Again, patches are more than welcome. And do feel free to call for a RC or > RM it yourself ;-) > > Gary > > > On Sat, Jun 16, 2018 at 2:34 PM Mark Thomas <ma...@apache.org> wrote: > >> On 16/06/18 21:14, Matt Sicker wrote: >> > On 16 June 2018 at 14:11, Mark Thomas <ma...@apache.org> wrote: >> > >> >> What is driving the desire to move to Java 8? >> >> >> > >> > What's driving the desire to maintain support for a seven year old >> release >> > of Java which is not supported without paying large sums of money to >> > Oracle? >> >> As I said, Tomcat 8 which has at least another 4 to 5 years of life in >> it, depends on DBCP 2 and has a specification mandated requirement to >> maintain compatibility with Java 7. >> >> There are ways the Tomcat community could work around this. Because Java >> 7 is EOL does not - on its own - strike me as a sufficiently good reason >> to create hassle for another ASF community. >> >> If there are new features in Java 8 we want to take advantage of or an >> update to the JDBC API that we want to support then fair enough. Those >> are good reasons but I'd like to see them explicitly articulated. >> >> Mark >> >> --------------------------------------------------------------------- >> 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
