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: <43625C68.5010301@sbcglobal.net>
Date: Fri, 28 Oct 2005 10:14:16 -0700
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>
In-Reply-To: <43623944.3040304@sun.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Rick Hillegas wrote:

>
>>> Scenario 1 - Fixing a Bug
>>>
>>> If I have it right the issue of "masking" comes up only when you have
>>> a mixed version environment.  Let's say the user is running with the
>>> 10.2 embedded driver and the 10.3 client driver.  Hopefully the user
>>> tells us "I'm using both 10.2 and 10.3."  Then we would fix the bug in
>>> both the 10.2 and 10.3 common code.
>>>
>>> If for some reason the user doesn't tell us this, we may fix the bug
>>> in the wrong version the first time, but after getting more info from
>>> the customer it will be clear that the bugfix should be ported to the
>>> other branch.
>>>
>>> We could have a policy that a common bug fix should be ported to all
>>> releases currently available and supported, but that seems like
>>> overkill and against the policy of "scratch your own itch" -- a bug
>>> should be fixed in the versions that matter to the user who has the
>>> bug.
>>>
>>> So I would argue when you do your test, you should make the fix in
>>> both versions of the common code and you should see no problem.
>>>
>>>
>>>   
>>
>>
>> Now *that* is user impact, developer impact and support impact.   The
>> fact that the bug fix revision level will regress with mixed jars if the
>> new jar is not first,  is an important product behaviour change to
>> mention.  I don't fix a bug normally for a single end user.  I fix a bug
>> for a product that is deployed (hopefully) to thousands of users.  You
>> are saying I need to know the configuration of all of those sites and
>> deal with them one by one. It's impossible.  And this is not 10.2 and
>> 10.3 mixing that we are talking about.  Installing some product with the
>> embedded driver at  10.2.1.1 might mask a client install at 10.2.1.19
>> and make something that is working just fine break in strange ways,
>> where as now the two are totally independent.  
>>
> I have lost the track of this argument. I am confused by the phrase
> "the bug fix revision level will regress with mixed jars". Can you
> help me understand how behavior regresses, that is, becomes worse? I'm
> only seeing two cases here:
>
> o The bug fix is applied to the wrong Derby version (the second one in
> the classpath), in which case it is a NOP. The experience for the
> customer will be that the bug was not fixed. However, no new
> regressions are introduced.
>
> o The bug fix is applied to the correct Derby version (the first one
> in the classpath). This fixes the bug for the customer. But what
> behavior is made worse here?
>
> A concrete example would help. Thanks.
>
>
This is the circumstance that Dan was talking about where jars are mixed
by circumstances.  I quote Dan's July 13 (Wow)
JIRA-289 comment.  Dan said ....
.
>In case it's not clear, this is the type of situation I'm talking about.
>Application A is a client server application and requires Derby client
10.2
>Application B is a local embedded Derby application and requires Derby
engine 10.3
>Now I want to run a client to A and B in the same JVM for some reason,
maybe portlets, maybe multiple applications
>in the same app server, maybe application B requires access to
application A.
>This would be supported with the current model, complete flexibility
because the code bases are separate.
>So do we want to lose this flexibility, or support it with the shared
code model?


Now lets change the versions a bit and say  our classpath is in this
order   derby.jar;derbyclient.jar
Application A is at 10.2.1.2   -  They just last week got a critical bug
fix in shared code and are happy to be running again.
Application B is at 10.1.2.1    -  They are running fine too but
planning to upgrade next week.

next week rolls around and the user installs their CD from Application B
which contains 10.2.1.1 .
Application B is working great,  but because the new derby.jar masks the
fix in derbyclient.jar, Application A is broken again.

I agree that jar mixing is an unfortunate reality,  but it is a reality
and has to stay safe and legal at least for a period of time while work
is done to make it rare.


Kathey