On 1/16/06, Kathey Marsden <[EMAIL PROTECTED]
> wrote:
Ramandeep Kaur wrote:
>Thanks to Kathey for looking into test failures.
>
>Attaching tmp and tmpstr files for autoGeneratedJdbc30 and holdCursorJDBC30.
>
>Please check out the attachments.
>
>
These do not look like compatibility problems.
holdCursorJDBC30 - Output changed with fix for DERBY-213
autoGeneratedJdbc30 matches the 10.2 master and looks like a changed output from the fix for DERBY-353.
I think there's another change required in the test harness to support this type of testing. There'll be need for test skipping, for sed-ing, and (hopefully minimal) canons for diffing. Is that being implemented?
I imagine something similar to what is currently in place for different JCC clients.
However, with the JCC clients, we always use the derbyTesting.jar of the server level. Because of the number of changes gone into 10.2 by now (I'd think, especially, the connection # output), there would be a large number of failures if one'd use the
10.2 derbyTesting.jar with 10.1-client-10.2 server testing. I assume that is why the 10.1 version derbyTesting.jar was picked.
But then, instead of only supporting the different clients, we'll also be supporting different server versions in the test harness/test files...Which would also possibly mean adding more code to an older version to support a newer version.
It seems trivial now, but what about future versions? Like, 10.3 server and 10.1 client? We'll have to keep adding - hopefully minor - changes to the 10.1 test harness...Especially if we have canons, we may need to keep modifying those canons both in multiple versions'
derbyTesting.jars.
Hopefully I am worrying about nothing...but I do want to mention this implication.
Myrna
