sebb wrote: > On 25/11/2009, Phil Steitz <[email protected]> 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). > > I'm not sure the source manipulation really matters. > It's always possible to recreate the modified source from the release > tag by running the Ant build. I think one can regard that as part of > the compilation process. > > Anyway the modified source can be included in the appropriate source archive. > > I think having separate code branches is going to be a lot more work > for not much gain. > > The build process will need to be carefully documented, but that only > has to be done once.
Thanks, Sebb. After sending I realized that my desire was really just to have a good tag, so in fact all I would need is separate tags - no need to branch. And you have made me feel better about even eliminating the separate tag and just publishing the "compatability jar" via documented process from the Ant build. Are you OK with the maven artifact names and locations? Phil > >> Feedback / better ideas welcome. >> >> Thanks! >> >> Phil >> >> >> >> >> >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
