db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Francois Orsini <francois.ors...@gmail.com>
Subject Re: Modular build, was: VOTE: Approach for sharing code
Date Tue, 20 Sep 2005 01:01:15 GMT
I think you meant 'org.apache.derby.common' in your examples. 

Now, if the common package versioning is well automated as part of 
generating a new release, then it is probably ok to have a new version being 
generated for every release.

Are you thinking that we would always see 'org.apache.derby.common' in the 
source tree and that the common pkg version suffix would only be added when 
a (new) release gets generated?


On 9/19/05, David W. Van Couvering <David.Vancouvering@sun.com> wrote:
> Hi, all. I've been letting this brew in my subconscious this weekend,
> with the strong belief that *somehow* there is a solution that can meet
> all of our requirements (simple architecture, ease-of-use,
> compatibility, no regressions, easy to maintain, reduce code duplication).
> I think I may have something that will do this, and your comments are
> much appreciated. There is a bit of overhead for the release process,
> but I think if we are going to have overhead, that's the place to do it.
> The principle is that for each release, the common package is unique.
> This is achieved by appending the release number to the package name.
> So for the 10.1.2 release the package name is org.apache.common_1012.
> In this way a consumer of the common classes for a given version is
> guaranteed to load the right classes and no conflicts or confusion occur.
> As part of the release process, when you make a branch for a release,
> you run a script that renames the common package to match your release
> name. This script does the following:
> - In the source, replace all instances of org.apache.common_<oldversion>
> with org.apache.common_<newversion>
> - Do an svn move of java/common/org/apache/common_<oldversion> to
> java/common/org/apache/common_<newversion>
> Because you are using svn move, although it's a bit confusing, all
> history is maintained and you can still use svn to do merges and ports
> of changes.
> The common package is put into both derby.jar and derby-client.jar, and
> we do not create a new JAR file.
> Thanks,
> David

View raw message