Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <4368F9A5.9040705@sbcglobal.net>
Date: Wed, 02 Nov 2005 09:38:45 -0800
From: Kathey Marsden <kmarsdenderby@sbcglobal.net>
User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803)
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Re: VOTE: Principles of sharing code
References: <435ACFBC.50906@sun.com> <435D2666.2040202@debrunners.com>
 <435D3B59.1070104@sun.com> <435D4797.40005@debrunners.com>
 <86k6g2vd4x.fsf@ugle.hatlen.net> <435ED5E3.4020100@debrunners.com>
 <435F0948.4050402@sbcglobal.net> <435FAE27.5000206@sun.com>
 <4360C189.80902@sbcglobal.net> <4361671E.3040007@sun.com>
 <43621EED.3040402@sbcglobal.net> <43623944.3040304@sun.com>
 <43625C68.5010301@sbcglobal.net> <43629DC5.60904@sun.com>
 <43629FAD.7020101@debrunners.com> <4362A96D.6090702@sun.com>
 <4362BC2B.6000704@debrunners.com> <43663663.1080200@sun.com>
In-Reply-To: <43663663.1080200@sun.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

David W. Van Couvering wrote:

> Thanks, Dan.  I would like to know if we need to have a vote on the
> overall principles of shared code or if people just want to see an
> examlpe implementation.  I am fine either way, although personally I'd
> like to make sure we agree on the principles before I spend too much
> time on an implementation.
>
I think the requirement for a vote, be it in principle or patch  comes
primarily from the resulting product behaviour changes. I think for the
changes  you have proposed, that means  reduced support for mixing
server and client jar versions.  I think I finally understand the change
in a way that I can explain it to users and support folks that are
affected by it  but know nothing about the internals of Derby, what's
shared or how,  and I think it goes like this:

Behaviour Change:

Derby will continue to allow  mixing different versions of
derbyclient.jar and derby.jar in the same JVM classpath but beginning
with Derby 10.2 this capability will be affected by classpath order.  If
the lower revision level jar  comes first in the classpath,  new
functionality and bug fixes may not be available, but functionality at
the lower revision level will not be affected.  Placing the higher
revision level jar first in the classpath will make the functionality
and bugfixes from  the higher revision level available. 

Example:
If a bug is fixed  in version 10.2.1.0 (1235)  and  a single JVM has a
client application  with version 10.2.1.0 (1234) derbyclient.jar  and 
an embedded application with 10.1.2.0 (1235) derby.jar in it's
classpath,  it may be necessary to either upgrade  the client version
to  10.1.2.0 (1235) or   make sure  derby.jar is first in the classpath 
for the embedded application to see the fix.

Does this sound like an accurate description of the behaviour change
from the user/support  perspective?    Is there anything else we should
watch out for in environments where jar versions are mixed?  Will
derbytools.jar be affected?  Just to be clear, I am not challenging
anything here.  I'm  just trying to understand and make sure I explain
this to others correctly and deal with it properly from a support
perspective.  

Thanks

Kathey