JBoss Hibernate 3.5 is sitting in the same position because it has to support both JDBC 3 and JDBC 4. There are obvious incompatibilities. For their purposes, they created a general abstraction and then allowed implementations to plug-in.
I would similarly follow suit. Produce separate assemblies such as: commons-dbcp-1.3.jar (main) commons-dbcp-jdbc3-1.3.jar (jdbc3 adapter) commons-dbcp-jdbc4-1.3.jar (jdbc4 adapter) Paul On Tue, Nov 24, 2009 at 6:23 PM, Phil Steitz <phil.ste...@gmail.com> wrote: > The 1.3 release of dbcp will support JDK 1.4, 1.5 (JDBC 3) and 1.6 > (JDBC 4). The Ant build in trunk will work with all three, > commenting out the JDBC 4 code when compiling under 1.4 or 1.5. > > It does not appear to be possible to produce a single binary jar > which will work for both JDBC 3 and 4, so we are going to need to > package two different 1.3 release jars. > > I would appreciate comments / better ideas on the following plan > > 1. Create a 1_3_JDBC3 branch copied from trunk > 2. Remove the JDBC4 code from the 1_3_JDBC branch > 3. Set the version identifier to 1.3-jdbc3 in the POM and Ant build > in the JDBC3 branch > 4. Change the maven group id in the trunk POM to the maven standard > (org.apache.commons) > 5. Create two full release distributions and tags (source, binary, > maven), one from trunk, using JDK 1.6 to build and package and one > from the JDBC3 branch. > 6. Publish commons-pool-1.3-jdbc3.jar to > commons-dbcp/commons-dbcp/1.3-jdbc3 > and commons-pool-1.3.jar to org/apache/commons/commons-dbcp/1.3 > > I would be OK adding jdbc4 to the JDBC 4 artifactId. The rationale > for leaving it as 1.3 and the sources in trunk is to signal that > this is the main development line. The rationale for separate > distros is that you end up with sources / tags / binaries all lined > up with simple reproducibility. Cutting a JDBC 3 branch leaves open > the possibility of future patch releases targeting JDBC 3. > > The disadvantage of this approach is that given the large number of > changes and bugfixes in 1.3, there will almost certainly be patch > releases to follow and it will be a mild PITA to maintain fixes in > both branches. > > I guess an alternative is to produce only one full distro, targeting > 1.6 with 1.3 identifier and org.apache.commons groupID and then just > publish a "compatability jar" to commons-dbcp/commons-dbcp/1.3-jdbc3 > compiled using 1.5. What I don't like about that is that there is > not a clean correspondence between a release tag and what gets > published (because of the source manipulation done by the Ant build). > > Feedback / better ideas welcome. > > Thanks! > > Phil > > > > > > > > > > --------------------------------------------------------------------- > 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
