[ http://issues.apache.org/jira/browse/DERBY-516?page=comments#action_12332013 ]
Rick Hillegas commented on DERBY-516: ------------------------------------- Thanks, David, for reviewing this patch so thoroughly. Based on your review, I will make several changes and resubmit this patch. Here are my responses to your comments: 1) No-one else has run this test yet. Thank you for voluteering to do so. If the instructions aren't clear enough, please let me know and I will fix them too. 2) Concerning the casing of my symbols: I have tried to follow the same casing policy which I use in Java code. I uppercase constants and I camelcase variables, arguments, and methods. 3) It's true that the embedded case isn't properly speaking part of a compatibility test. It's there as a sanity check to track discrepancies between the embedded and network clients. I will add a comment to explain this. 4) It's also true that jdbcTrunk is never invoked. It's a top level entry point which I included to help me debug the test and harness. It lets you run just one combination. I left it in because I expect it will be very useful as developers add additional cases to this test. I will beef up its comment to explain this. 5) In general, I will beef up my comments. I apologize for the cryptic names TD and T_CN. Originally these classes had more useful names: TypeDescriptor and TypeCoercion. I had to truncate these names in order to fit the ALL_TYPES and COERCIONS tables onto a readable screen. I think I've given up on this fond dream for ALL_TYPES and so there's no reason that TD couldn't be replaced with its more useful name. I will make this change. I would like to leave T_CN short for the reason I just gave, but I will add a comment to its class header explaining this oddity. 6) Similarly, I opted for Y and _ instead of Y and N because it made the table more readable. I experimented with a couple combinations and this is the one which made the salient Y really leap out at the reader. 7) I agree with your objection to my exception handling in the startup code. I will fix this as you suggest. 8) You are right, I am only testing the 10.0 datatypes in this first cut of the test. As I re-enable and add new datatypes, I will incorporate them in this test too. When I add a new datatype, it will be tested in all combinations in which the server lets a customer declare that datatype. In the current state of the test, there is only one minor (canonized) incompatibility, which I have logged as bug 584: the DRDA clients conflate NUMERIC and DECIMAL. No doubt, as we add more test cases, we will find more important existing incompatibilities. I will also address the issue which you and Dan discussed in email: I will amend the scripts and BUILDING.txt to tell the developer that she should be able to download any version of JUnit at level 3.8.1 or higher. > Need to incorporate client backward/forward compatibility testing into > testing procedures. > ------------------------------------------------------------------------------------------- > > Key: DERBY-516 > URL: http://issues.apache.org/jira/browse/DERBY-516 > Project: Derby > Type: Test > Components: Test > Versions: 10.1.1.0 > Reporter: Kathey Marsden > Assignee: Rick Hillegas > Attachments: bug516.diff > > Need to incorporate client backward/forward compatibility testing into > testing procedures. > New versions of the Derby network server should work with old versions of the > network client. New versions of the Derby network client should work with > old versions of the server. Currently that means that the 10.1 client should > be tested on the trunk. The 10.2 client definitely needs to be tested > with the 10.1 server before release, but it would be good to start testing > snapshots of 10.2 client on the 10.1 branch earlier. > > Note: > Bug fixes may mean that the canons differ for different versions. > The test harness I think is set up to allow different masters for different > versions. It at least has that functionality for the DerbyNet framework > and it could be expanded to cover DerbyNetClient. The way it works is that > the harness checks for a masters in the following order: > functionTests/master/<framework>/ver<version> > functionTests/master/<framework>/ > functionTests/master/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
