db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W. Van Couvering" <David.Vancouver...@Sun.COM>
Subject Re: VOTE: Principles of sharing code
Date Fri, 28 Oct 2005 16:55:26 GMT
I had to smile, your statement "now *that* is user impact" sounded like 
Perry Mason nailing a defense witness.  I think you have caught me -- 
there is some user impact -- but less than you imply, which I will 
discuss below.

I stand by my belief that sharing code has enough value to merit us 
dealing with this.

 From supporting customers in an environment with duplicated code, I can 
tell you that you have exactly the same problem you are describing here. 
  It is so easy for a developer to fix a bug in copy A of some code but 
forget to fix it in copy B.  The end user experience is the same -- I 
thought you fixed this bug, but you didn't!  You also avoid strange 
behavior such as slightly different SQL States between client and 
server, or a slightly different treatment of a data type, or slightly 
different driver behavior, or the fact that JDBC feature A is supported 
in the embedded engine but not in the network client -- all things we 
are trying to solve.

The power of leverage and productivity that you get with common code is 
also significant.  A developer need only build and test functionality 
once, rather than twice or even three times (we have I think at least 
four different implementations of internationalization code in our code 
base -- tools, client, network server and engine).  What about when we 
want to add a logging infrastructure, or monitoring, or...?  Are we 
going to have two or three copies of these as well?

After careful consideration, I have come to the conclusion that I also 
am not willing to create a strange and somewhat disturbing development 
environment through cloning classes and those sorts of solutions we have 
looked at in the past.

In terms of your particular issue, I'd like to challenge that it is as 
bad as you say it is.

Why would someone want to run at different patch versions of the same 
minor version in the same VM (as in your example, 10.2.1.1 masking 
10.2.1.19)?   Maybe I'm missing something, but isn't the point of mixed 
versions to support running with new/old functionality, which doesn't 
happen between patch or maintenance releases?  So it seems you would see 
at a minimum different minor versions (e.g. 10.2 and 10.3) in a mixed 
version environment.

So, as I see it, this can be solved in one of two ways:

Solution A - Port the Fix

- Have a policy that any bug fix to common code must be ported to the 
latest patch branches of the same minor revision where the bug was found 
(e.g. the bugfix should be ported to 10.2.0.1, 10.3.3.2, 10.4.0.1)

- The user in a mixed environment must get the latest patch release for 
each revision they are using.  They are likely doing this anyway.  Yes, 
I agree, this a change in our requirements and is thus arguably user 
impact (e.g. a change in how our user experiences our product, although 
I think I agree with Rick this is not a regression).

- A user running in a mixed environment with two major revisions may 
encounter that the bug was not fixed after a patch, but this should be 
fairly easy to resolve.  Again, a little user impact, but again not what 
I'd consider a regression.


Solution B - Separate Out the Common Code

You do not have this problem if the code common between the network 
client and engine is placed into a separate jar file.  Yes, again, user 
impact, but not a regression.  According to the Jakarta Commons 
versioning guidelines that we have proposed to follow, this is an 
"interface-compatible change" and only requires a new point release 
(e.g. from 10.1 to 10.2). See 
http://jakarta.apache.org/commons/releases/versioning.html

One could raise the concern that code shared between network client and 
network server should be in a different jar file so that the embedded 
footprint doesn't grow unnecessarily.  But I don't see where you would 
ever run a different version of the network server and the network 
client in the same VM.  So if there is code that is common between the 
network server and the network client, I argue that that can safely be 
embedded in derbyclient.jar and derbynet.jar.

I can go either way, but my preference is toward Solution B.  This has a 
one-time user impact (and not a very large one) and we don't have to 
worry about users being surprised that a bug wasn't fixed when they 
upgraded one version but not the other.

Thanks,

David


Kathey Marsden wrote:
> 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  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. 
> 
> Kathey
> 
> 
> 

Mime
View raw message