On 25/11/2009, Phil Steitz <[email protected]> wrote: > 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?
Sorry, no idea if they are sensible or not. > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
