db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: VOTE: Principles of sharing code
Date Fri, 28 Oct 2005 14:44:20 GMT

>>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.

Mime
View raw message