commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject [dbcp] 1.3 release packaging
Date Wed, 25 Nov 2009 00:23:33 GMT
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
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
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.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message