db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kathey Marsden <kmarsdende...@sbcglobal.net>
Subject Re: VOTE: Principles of sharing code
Date Fri, 28 Oct 2005 17:14:16 GMT
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 might mask a client install at
>> 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
>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   -  They just last week got a critical bug
fix in shared code and are happy to be running again.
Application B is at    -  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 .
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.


View raw message