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
begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard
