Rick Hillegas wrote: > > > What if the metadata test internally verified that the version numbers > from the client driver agreed with the values in dnc.properties? Then > we wouldn't have to hard code version numbers anywhere: not in the > test code and not in the canons. We could remove the metadata canons > from the list in the bumplastdigit target. > I think some centralized location is good but I think dnc.properties is maybe not quite right because:
1) It would be pulling the version right out of the jar being tested so I think that if we did this and plopped down a 10.1 derbyclient.jar, the test would pass with a 10.2 derbyTesting.jar. 2) The test would fail when testing the embedded driver without derbyclient.jar. 3) When testing the jcc driver, you couldn't really get a version for getDatabaseProductVersion() because there is no dnc.properties available. Anyway, I better get back to these DRDA patches and so I'll end my journey here on contemplating the cyclical version testing conundrum. Might you consider submitting a patch to fix the jdk 1.3.1 failures without the version change? There was an interesting conversation on the list recently about the value of separating of patches. I think that this is a case where it is appropriate. Thanks Kathey
