Andrew McIntyre wrote: > > 10.2 tools : 10.1 client : 10.1 engine = 10.2 client / 10.2 engine > 10.1 client : 10.2 tools : 10.1 engine = 10.1 client / 10.2 engine > 10.1 derby : 10.1 engine : 10.2 tools = 10.1 client / 10.1 engine > > Of course, I'm not sure what sort of usage (outside of our tests) > would lead to such a pattern as the above. I'd expand with e.g. 10.2 > derby.jar in there, but that would lead to far too many premutations > to stick in an email. But you get the idea.
Looking at the classpaths where the behaviour changes for applications that are expecting the earlier versions: Let's assume this class path was set up by three independent applications, A, B & C. 10.2 tools (A) : 10.1 client (B) : 10.1 engine (C) If application A is using engine *and* client then making the DERBY-1063 changes makes no difference. Without the changes the explicit setting of classpath required would change the version one of B or C is expecting. If application A is using client *or* engine then making the DERBY-1063 changes only makes a difference if A ships the jar file it is not using. Since this is a 10.2 user, and they must have read the documentation that said they only needed tools in the classpath, then maybe they will have read any warnings we also put in there about not shipping jars you don't need. If application A is really just using ij/dblook, with a different JDBC driver, maybe Oracle, maybe DB2's JCC for a remote derby engine, DERBY-1063 does make a difference, but only if application A is shipping derbyclient.jar and/or derbyengine.jar. Do we care about this usage enough to hold back usability improvements in Derby? Is anyone using ij as client to other databases? In this case they might not have read the docs, maybe they were using 10.1/10.0 and just upgraded, no changes were needed as they are just using ij/dblook and they only ever needed tools.jar for that. Then the underlying fact is that we do work hard for compatibility, how badly will it affect applications B or C in the above cases that they are picking up the newer client or engine? They will continue to work, that's our forward compatibility goal, applications continue to work with no change. I think the difference to shared code, is that mixed jars in a simple shared code model could break each other, or reduce functionality, that doesn't happen here. Dan.
