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 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. > > 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 10.2 >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 10.2.1.2 - They just last week got a critical bug fix in shared code and are happy to be running again. Application B is at 10.1.2.1 - 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 10.2.1.1 . 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. Kathey
