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 12:51:57 GMT
David W. Van Couvering 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. 


View raw message