Hi Kathey,
I don't want to pull on a big ball of yarn, either. Do you think the
following changes will be adequate?
1) Remove the hard-coded release-specific variables from the metadata test.
2) Go back to printing release variables in the canons.
3) Update the bumplastdigit target to include the new canons.
Thanks,
-Rick
Kathey Marsden wrote:
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
