Hi Kathey,
Thanks for pointing me at this piece of the release machinery. I have a
naive question: If we have this programmatic way of generating new
release numbers and then poking them into test canons, what are we
testing here? At first blush, it seems that we are just verifying that
this special release target successfully propagates numbers into canons.
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.
What do you think?
Regards,
-Rick
Kathey Marsden wrote:
Rick Hillegas wrote:
Hi Kathey,
I have clipped to JIRA-499 a fix for these regressions. Thanks for the
heads-up about the version numbers in the canons. I finessed that
issue by removing the volatile numbers from the canons. Instead, the
metadata test now compares version numbers internally and only emits
diff-triggering output if it detects a discrepancy. Keeping this test
in sync with the version variables in dnc.properties now involves a
couple edits to metadata.java rather than updating 10 canons.
I think I don't like this approach of putting the derby version in the
metadata a test because it doesn't provide a centralized place to bump
the version for all the tests affected. Right now to bump the version
you run the tools/bumplastdigit target (See
http://wiki.apache.org/db-derby/DerbySnapshotOrRelease). With this
patch, you would have to run that plus change this one test. Also I
think the release instructions would need to be changed,.
Thanks
Kathey
