On 5/30/13 1:47 AM, Emmanuel Bourg wrote: > 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.
Sorry for stupidity above. I was not thinking through the consequences of the gump-esque build process. I guess if we really want to support everything building from source with no binary incompatible change, we are going to have to support the 1.x code suitably hacked forward indefinitely. This is not a happy prospect; but given how widely used DBCP is, we should do it. Given this, I agree with your original proposal that we build in another layer of filtering to the 1.x code base, with the no-op patch merged in. I will play with this over the weekend and see if I can get an Ant build working that extends what we do now to produce 1.3.x from the 1.4.x sources to also source a 1.5.x. Phil > > >> 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
