Le 30/05/2013 06:12, Phil Steitz a écrit : > Only because we have not yet released 2.0. If we focus on doing > that, their problem is solved. That was basically my point above.
Let's suppose we release a binary incompatible 2.0 version that compiles with Java 7, the Debian/Fedora maintainers will have to patch every packaged software that depends on DBCP 1.x to use the new API until the change is applied upstream (if ever it's applied). If the behavior of the API changed they'll also have to endorse the responsibility for testing their changes. That's worse than patching DBCP 1.x. > Rather than hacking more compile filters so that 1.x can work for 3 > different - incompatible - JDBC versions, we should split cleanly. > We are not that far away from being able to release 2.0. Then > whoever wants to target JDK 1.7 can use those sources. To avoid the proliferation of maintenance releases we may state that we support only the last two revisions of JDBC. Thus we would only support Java 7 (DBCP 1.5.x) and Java 6 (DBCP 1.4.x), and we abandon DBCP 1.3. Once Java 8 is released we drop Java 6 support (be it with DBCP 1.x or DBCP 2.x). Emmanuel Bourg
signature.asc
Description: OpenPGP digital signature
