commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [dbcp] 1.3 release packaging
Date Wed, 25 Nov 2009 00:47:46 GMT
On 25/11/2009, Phil Steitz <phil.steitz@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).

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.

>  Feedback / better ideas welcome.
>
>  Thanks!
>
>  Phil
>
>
>
>
>
>
>
>
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>  For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message