You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Kathey Marsden (JIRA)" <de...@db.apache.org> on 2005/08/18 16:20:11 UTC
[jira] Created: (DERBY-516) Need to incorporate client backward/forward compatibility testing into testing procedures.
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
Fix For: 10.1.1.1, 10.2.0.0
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
Re: [jira] Updated: (DERBY-516) Need to incorporate client
backward/forward compatibility testing into testing procedures.
Posted by Rick Hillegas <Ri...@Sun.COM>.
Hi Dan,
The short answer is no.
The long answer is that instrumenting the test run with -Dverbose=true
didn't yield any more clues. I began to suspect that the wrong client
was expected in the jdbcapi suite, where I had placed the test. So I
moved it to derbynetmats. There the test ran cleanly. I don't have any
good theories. I stopped speculating after the test ran inside derbynetmats.
Regards,
-Rick
Daniel John Debrunner wrote:
>Rick Hillegas (JIRA) wrote:
>
>
>
>> [ http://issues.apache.org/jira/browse/DERBY-516?page=all ]
>>
>>Rick Hillegas updated DERBY-516:
>>--------------------------------
>>
>> Attachment: bug516.diff
>>
>>Hi, David: I have amended this patch as you suggested. I ran derbyall and one test failed: dataSourcePermissions_net. When I ran derbynetmats by itself, this test passed so I'm writing it off as some kind of environmental hiccup. The files in this amended submission are:
>>
>>
>
>Did you resolve the secuiryt manager problem? If so, I'd be interested
>in what the issue was and the resolution.
>
>Thanks,
>Dan.
>
>
>
>
>
>
Re: [jira] Updated: (DERBY-516) Need to incorporate client backward/forward
compatibility testing into testing procedures.
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Rick Hillegas (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/DERBY-516?page=all ]
>
> Rick Hillegas updated DERBY-516:
> --------------------------------
>
> Attachment: bug516.diff
>
> Hi, David: I have amended this patch as you suggested. I ran derbyall and one test failed: dataSourcePermissions_net. When I ran derbynetmats by itself, this test passed so I'm writing it off as some kind of environmental hiccup. The files in this amended submission are:
Did you resolve the secuiryt manager problem? If so, I'd be interested
in what the issue was and the resolution.
Thanks,
Dan.
>
Re: [jira] Updated: (DERBY-516) Need to incorporate client
backward/forward compatibility testing into testing procedures.
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
Why yes it is, thanks. I remove my suggestion.
David
Daniel John Debrunner wrote:
> David W. Van Couvering wrote:
>
>
>>I like to start by applying a patch to the revision level that the patch
>>was built with. That way I can make very sure I applied things
>>correctly -- I can diff the output of svn status and svn diff with what
>>the contributor provided. This is especially important when the
>>contribution includes files that are added (especially new empty files
>>like empty test master files), which I actually have to add by hand.
>>
>>Once that looks good, I do an svn update with no -r option to update the
>>tree to the head of the trunk. If at this point I get errors, then,
>>yes, I would complain to the contributor, but I want to make sure I
>>applied the patch correctly first.
>>
>>Maybe that's not how everyone does it, but that's how I like to do it,
>>so that's why I was suggesting the revision number. I can also do it by
>>date, but the revision number is more accurate.
>
>
> Ok sounds fine, isn't the svn revision in the svn diff output though?
>
> Dan.
>
Re: [jira] Updated: (DERBY-516) Need to incorporate client backward/forward
compatibility testing into testing procedures.
Posted by Daniel John Debrunner <dj...@debrunners.com>.
David W. Van Couvering wrote:
> I like to start by applying a patch to the revision level that the patch
> was built with. That way I can make very sure I applied things
> correctly -- I can diff the output of svn status and svn diff with what
> the contributor provided. This is especially important when the
> contribution includes files that are added (especially new empty files
> like empty test master files), which I actually have to add by hand.
>
> Once that looks good, I do an svn update with no -r option to update the
> tree to the head of the trunk. If at this point I get errors, then,
> yes, I would complain to the contributor, but I want to make sure I
> applied the patch correctly first.
>
> Maybe that's not how everyone does it, but that's how I like to do it,
> so that's why I was suggesting the revision number. I can also do it by
> date, but the revision number is more accurate.
Ok sounds fine, isn't the svn revision in the svn diff output though?
Dan.
Re: [jira] Updated: (DERBY-516) Need to incorporate client
backward/forward compatibility testing into testing procedures.
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
I like to start by applying a patch to the revision level that the patch
was built with. That way I can make very sure I applied things
correctly -- I can diff the output of svn status and svn diff with what
the contributor provided. This is especially important when the
contribution includes files that are added (especially new empty files
like empty test master files), which I actually have to add by hand.
Once that looks good, I do an svn update with no -r option to update the
tree to the head of the trunk. If at this point I get errors, then,
yes, I would complain to the contributor, but I want to make sure I
applied the patch correctly first.
Maybe that's not how everyone does it, but that's how I like to do it,
so that's why I was suggesting the revision number. I can also do it by
date, but the revision number is more accurate.
Thanks,
David
Daniel John Debrunner wrote:
> David W. Van Couvering wrote:
>
>
>>No, that's it. I think it would be a great habit for all of us to list
>>the svn info revision number along with the svn status when submitting a
>>patch.
>
>
>>>David W. Van Couvering wrote:
>>>
>>>
>>>>Thanks, Rick. Can you add a comment with the SVN revision number of
>>>>your sandbox? This helps me merge the patch into the right snapshot
>>>>of the codeline.
>
>
> I'm missing something here, patches should be merged into the latest
> version of a codeline, not an old version. If the patch doesn't merge
> cleanly then either the committer can figure it out, or they can bounce
> it back to the contributor to say please merge with the latest and
> re-submit. Getting the contributor to merge is the best approach, since
> they understand the code changes the best.
>
> What are you trying to achieve by using an old codeline?
>
> Dan.
>
>
Re: [jira] Updated: (DERBY-516) Need to incorporate client backward/forward
compatibility testing into testing procedures.
Posted by Daniel John Debrunner <dj...@debrunners.com>.
David W. Van Couvering wrote:
> No, that's it. I think it would be a great habit for all of us to list
> the svn info revision number along with the svn status when submitting a
> patch.
>> David W. Van Couvering wrote:
>>
>>> Thanks, Rick. Can you add a comment with the SVN revision number of
>>> your sandbox? This helps me merge the patch into the right snapshot
>>> of the codeline.
I'm missing something here, patches should be merged into the latest
version of a codeline, not an old version. If the patch doesn't merge
cleanly then either the committer can figure it out, or they can bounce
it back to the contributor to say please merge with the latest and
re-submit. Getting the contributor to merge is the best approach, since
they understand the code changes the best.
What are you trying to achieve by using an old codeline?
Dan.
Re: [jira] Updated: (DERBY-516) Need to incorporate client
backward/forward compatibility testing into testing procedures.
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
No, that's it. I think it would be a great habit for all of us to list
the svn info revision number along with the svn status when submitting a
patch.
Thanks,
David
Rick Hillegas wrote:
> Hi David,
>
> Inside the patch, all of the pre-existing files say that they are at
> revision 325900. This is also the revision of my trunk directory as
> reported by svn info. Is this the revision number I should add to the
> JIRA case? Or is there some other subversion command which I should use
> to get the information you need?
>
> Thanks,
> -Rick
>
> David W. Van Couvering wrote:
>
>> Thanks, Rick. Can you add a comment with the SVN revision number of
>> your sandbox? This helps me merge the patch into the right snapshot
>> of the codeline.
>>
>> David
>>
>> Rick Hillegas (JIRA) wrote:
>>
>>> [ http://issues.apache.org/jira/browse/DERBY-516?page=all ]
>>>
>>> Rick Hillegas updated DERBY-516:
>>> --------------------------------
>>>
>>> Attachment: bug516.diff
>>>
>>> Hi, David: I have amended this patch as you suggested. I ran derbyall
>>> and one test failed: dataSourcePermissions_net. When I ran
>>> derbynetmats by itself, this test passed so I'm writing it off as
>>> some kind of environmental hiccup. The files in this amended
>>> submission are:
>>>
>>> M tools\ant\properties\compilepath.properties
>>> M java\build\org\apache\derbyBuild\build.xml
>>> M java\testing\README.htm
>>> A
>>> java\testing\org\apache\derbyTesting\functionTests\tests\compatibility
>>> A
>>> java\testing\org\apache\derbyTesting\functionTests\tests\compatibility\README.html
>>>
>>> A
>>> java\testing\org\apache\derbyTesting\functionTests\tests\compatibility\testScript.xml
>>>
>>> A
>>> java\testing\org\apache\derbyTesting\functionTests\tests\compatibility\Pinger.java
>>>
>>> A
>>> java\testing\org\apache\derbyTesting\functionTests\tests\compatibility\JDBCDriverTest.java
>>>
>>> A
>>> java\testing\org\apache\derbyTesting\functionTests\tests\compatibility\build.xml
>>>
>>> A
>>> java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\CompatibilityTest.java
>>>
>>> A
>>> java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\CompatibilityTest_app.properties
>>>
>>> M
>>> java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\copyfiles.ant
>>>
>>> M
>>> java\testing\org\apache\derbyTesting\functionTests\harness\Sed.java
>>> A
>>> java\testing\org\apache\derbyTesting\functionTests\master\CompatibilityTest.out
>>>
>>> M
>>> java\testing\org\apache\derbyTesting\functionTests\suites\derbynetmats.runall
>>>
>>> A
>>> java\testing\org\apache\derbyTesting\functionTests\util\DerbyJUnitTest.java
>>>
>>> M java\testing\build.xml
>>> M java\client\org\apache\derby\client\net\Reply.java
>>> M BUILDING.txt
>>> M build.xml
>>>
>>>
>>>> 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/
>>>
>>>
>>>
>>>
>
Re: [jira] Updated: (DERBY-516) Need to incorporate client
backward/forward compatibility testing into testing procedures.
Posted by Rick Hillegas <Ri...@Sun.COM>.
Hi David,
Inside the patch, all of the pre-existing files say that they are at
revision 325900. This is also the revision of my trunk directory as
reported by svn info. Is this the revision number I should add to the
JIRA case? Or is there some other subversion command which I should use
to get the information you need?
Thanks,
-Rick
David W. Van Couvering wrote:
> Thanks, Rick. Can you add a comment with the SVN revision number of
> your sandbox? This helps me merge the patch into the right snapshot
> of the codeline.
>
> David
>
> Rick Hillegas (JIRA) wrote:
>
>> [ http://issues.apache.org/jira/browse/DERBY-516?page=all ]
>>
>> Rick Hillegas updated DERBY-516:
>> --------------------------------
>>
>> Attachment: bug516.diff
>>
>> Hi, David: I have amended this patch as you suggested. I ran derbyall
>> and one test failed: dataSourcePermissions_net. When I ran
>> derbynetmats by itself, this test passed so I'm writing it off as
>> some kind of environmental hiccup. The files in this amended
>> submission are:
>>
>> M tools\ant\properties\compilepath.properties
>> M java\build\org\apache\derbyBuild\build.xml
>> M java\testing\README.htm
>> A
>> java\testing\org\apache\derbyTesting\functionTests\tests\compatibility
>> A
>> java\testing\org\apache\derbyTesting\functionTests\tests\compatibility\README.html
>>
>> A
>> java\testing\org\apache\derbyTesting\functionTests\tests\compatibility\testScript.xml
>>
>> A
>> java\testing\org\apache\derbyTesting\functionTests\tests\compatibility\Pinger.java
>>
>> A
>> java\testing\org\apache\derbyTesting\functionTests\tests\compatibility\JDBCDriverTest.java
>>
>> A
>> java\testing\org\apache\derbyTesting\functionTests\tests\compatibility\build.xml
>>
>> A
>> java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\CompatibilityTest.java
>>
>> A
>> java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\CompatibilityTest_app.properties
>>
>> M
>> java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\copyfiles.ant
>>
>> M
>> java\testing\org\apache\derbyTesting\functionTests\harness\Sed.java
>> A
>> java\testing\org\apache\derbyTesting\functionTests\master\CompatibilityTest.out
>>
>> M
>> java\testing\org\apache\derbyTesting\functionTests\suites\derbynetmats.runall
>>
>> A
>> java\testing\org\apache\derbyTesting\functionTests\util\DerbyJUnitTest.java
>>
>> M java\testing\build.xml
>> M java\client\org\apache\derby\client\net\Reply.java
>> M BUILDING.txt
>> M build.xml
>>
>>
>>> 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/
>>
>>
>>
Re: [jira] Updated: (DERBY-516) Need to incorporate client
backward/forward compatibility testing into testing procedures.
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
Thanks, Rick. Can you add a comment with the SVN revision number of
your sandbox? This helps me merge the patch into the right snapshot of
the codeline.
David
Rick Hillegas (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/DERBY-516?page=all ]
>
> Rick Hillegas updated DERBY-516:
> --------------------------------
>
> Attachment: bug516.diff
>
> Hi, David: I have amended this patch as you suggested. I ran derbyall and one test failed: dataSourcePermissions_net. When I ran derbynetmats by itself, this test passed so I'm writing it off as some kind of environmental hiccup. The files in this amended submission are:
>
> M tools\ant\properties\compilepath.properties
> M java\build\org\apache\derbyBuild\build.xml
> M java\testing\README.htm
> A java\testing\org\apache\derbyTesting\functionTests\tests\compatibility
> A java\testing\org\apache\derbyTesting\functionTests\tests\compatibility\README.html
> A java\testing\org\apache\derbyTesting\functionTests\tests\compatibility\testScript.xml
> A java\testing\org\apache\derbyTesting\functionTests\tests\compatibility\Pinger.java
> A java\testing\org\apache\derbyTesting\functionTests\tests\compatibility\JDBCDriverTest.java
> A java\testing\org\apache\derbyTesting\functionTests\tests\compatibility\build.xml
> A java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\CompatibilityTest.java
> A java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\CompatibilityTest_app.properties
> M java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\copyfiles.ant
> M java\testing\org\apache\derbyTesting\functionTests\harness\Sed.java
> A java\testing\org\apache\derbyTesting\functionTests\master\CompatibilityTest.out
> M java\testing\org\apache\derbyTesting\functionTests\suites\derbynetmats.runall
> A java\testing\org\apache\derbyTesting\functionTests\util\DerbyJUnitTest.java
> M java\testing\build.xml
> M java\client\org\apache\derby\client\net\Reply.java
> M BUILDING.txt
> M build.xml
>
>
>>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/
>
>
[jira] Updated: (DERBY-516) Need to incorporate client backward/forward compatibility testing into testing procedures.
Posted by "Rick Hillegas (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-516?page=all ]
Rick Hillegas updated DERBY-516:
--------------------------------
Attachment: bug516.diff
Hi, David: I have amended this patch as you suggested. I ran derbyall and one test failed: dataSourcePermissions_net. When I ran derbynetmats by itself, this test passed so I'm writing it off as some kind of environmental hiccup. The files in this amended submission are:
M tools\ant\properties\compilepath.properties
M java\build\org\apache\derbyBuild\build.xml
M java\testing\README.htm
A java\testing\org\apache\derbyTesting\functionTests\tests\compatibility
A java\testing\org\apache\derbyTesting\functionTests\tests\compatibility\README.html
A java\testing\org\apache\derbyTesting\functionTests\tests\compatibility\testScript.xml
A java\testing\org\apache\derbyTesting\functionTests\tests\compatibility\Pinger.java
A java\testing\org\apache\derbyTesting\functionTests\tests\compatibility\JDBCDriverTest.java
A java\testing\org\apache\derbyTesting\functionTests\tests\compatibility\build.xml
A java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\CompatibilityTest.java
A java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\CompatibilityTest_app.properties
M java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\copyfiles.ant
M java\testing\org\apache\derbyTesting\functionTests\harness\Sed.java
A java\testing\org\apache\derbyTesting\functionTests\master\CompatibilityTest.out
M java\testing\org\apache\derbyTesting\functionTests\suites\derbynetmats.runall
A java\testing\org\apache\derbyTesting\functionTests\util\DerbyJUnitTest.java
M java\testing\build.xml
M java\client\org\apache\derby\client\net\Reply.java
M BUILDING.txt
M build.xml
> 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
[jira] Updated: (DERBY-516) Need to incorporate client backward/forward compatibility testing into testing procedures.
Posted by "Rick Hillegas (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-516?page=all ]
Rick Hillegas updated DERBY-516:
--------------------------------
Attachment: (was: bug516.diff)
> 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
>
> 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
Re: [jira] Commented: (DERBY-516) Need to incorporate client
backward/forward compatibility testing into testing procedures.
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
HI, RICK. I ALSO AM NOT WILLING TO SEND YOU TO THE STAKE FOR THIS ONE.
IF I WERE TO USE ANT WITHOUT ANY PRVEVIOUS EXPOSURE I WOULD PROBABLY
USE CAPS TOO. SO GO AHEAD AND KEEP IT AS IS!!!!
:)
DAVID
Rick Hillegas wrote:
> Hi David,
>
> Thanks for vetting my responses. One nub remains:
>
> I will be happy to change my symbol casing if you feel passionately
> about this. I think, however, that our existing ant scripts are fairly
> poor examples of ant usage. For instance, they do not take advantage of
> the -projecthelp machinery and they jump through crazy hoops because
> they don't understand custom ant tasks. I think symbol casing is just
> one example of ant style and usage which needs improvement across our
> scripts. I, however, am not willing to go to the stake for this heresy
> and I will defer to your judgment. Please let me know what you think. :)
>
> Cheers,
> -Rick
>
> David W. Van Couvering wrote:
>
>>
>>>
>>> 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.
>>
>>
>>
>> I am not sure if the same casing policy applies in Ant, at least I
>> haven't seen that in the build.xml files we have.
>>
>
Re: [jira] Commented: (DERBY-516) Need to incorporate client
backward/forward compatibility testing into testing procedures.
Posted by Rick Hillegas <Ri...@Sun.COM>.
Hi David,
Thanks for vetting my responses. One nub remains:
I will be happy to change my symbol casing if you feel passionately
about this. I think, however, that our existing ant scripts are fairly
poor examples of ant usage. For instance, they do not take advantage of
the -projecthelp machinery and they jump through crazy hoops because
they don't understand custom ant tasks. I think symbol casing is just
one example of ant style and usage which needs improvement across our
scripts. I, however, am not willing to go to the stake for this heresy
and I will defer to your judgment. Please let me know what you think. :)
Cheers,
-Rick
David W. Van Couvering wrote:
>
>>
>> 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.
>
>
> I am not sure if the same casing policy applies in Ant, at least I
> haven't seen that in the build.xml files we have.
>
Re: [jira] Commented: (DERBY-516) Need to incorporate client
backward/forward compatibility testing into testing procedures.
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
Rick Hillegas (JIRA) wrote:
> [ 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.
OK
>
> 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.
I am not sure if the same casing policy applies in Ant, at least I
haven't seen that in the build.xml files we have.
>
> 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.
OK, sounds good.
>
> 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.
OK
>
> 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.
Thanks.
>
> 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.
Perhaps you can add a comment to explain this; it takes a double-take
reading the code to understand what's up here.
>
> 7) I agree with your objection to my exception handling in the startup code. I will fix this as you suggest.
OK
>
> 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.
OK
>
> 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.
OK, great.
It's looking good, once I do a run of the compatibility tests and they
look OK it should be good to go.
David
>
>
>>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/
>
>
[jira] Commented: (DERBY-516) Need to incorporate client backward/forward compatibility testing into testing procedures.
Posted by "Rick Hillegas (JIRA)" <de...@db.apache.org>.
[ 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
[jira] Reopened: (DERBY-516) Need to incorporate client backward/forward compatibility testing into testing procedures.
Posted by "Kathey Marsden (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-516?page=all ]
Kathey Marsden reopened DERBY-516:
----------------------------------
I am reopening this bug as Rick plans to bring this test into derbyall by checking in the 10.1.1.0 release so that compatiblity testing with the first official derby release can be included in derbyall.
Thanks Rick !
> 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
[jira] Updated: (DERBY-516) Need to incorporate client
backward/forward compatibility testing into testing procedures.
Posted by "Dag H. Wanvik (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dag H. Wanvik updated DERBY-516:
--------------------------------
Issue Type: Improvement (was: Test)
> Need to incorporate client backward/forward compatibility testing into testing procedures.
> -------------------------------------------------------------------------------------------
>
> Key: DERBY-516
> URL: https://issues.apache.org/jira/browse/DERBY-516
> Project: Derby
> Issue Type: Improvement
> Components: Test
> Affects Versions: 10.1.1.0
> Reporter: Kathey Marsden
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-516) Need to incorporate client backward/forward compatibility testing into testing procedures.
Posted by "Rick Hillegas (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-516?page=all ]
Rick Hillegas updated DERBY-516:
--------------------------------
Attachment: bug516.diff
Incorporate Andrew's suggestion:
1) Amended BUILDING.txt and README.htm.
2) Moved junit jar symbol from compilepath to extrapath and adjusted build files accordingly.
3) Eliminated vacuous Reply.java
Contents of new patch:
M tools\ant\properties\extrapath.properties
M java\build\org\apache\derbyBuild\build.xml
M java\testing\README.htm
A java\testing\org\apache\derbyTesting\functionTests\tests\compatibility
A java\testing\org\apache\derbyTesting\functionTests\tests\compatibility\README.html
A java\testing\org\apache\derbyTesting\functionTests\tests\compatibility\testScript.xml
A java\testing\org\apache\derbyTesting\functionTests\tests\compatibility\Pinger.java
A java\testing\org\apache\derbyTesting\functionTests\tests\compatibility\JDBCDriverTest.java
A java\testing\org\apache\derbyTesting\functionTests\tests\compatibility\build.xml
A java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\CompatibilityTest.java
M java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\build.xml
A java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\CompatibilityTest_app.properties
M java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\copyfiles.ant
M java\testing\org\apache\derbyTesting\functionTests\harness\Sed.java
A java\testing\org\apache\derbyTesting\functionTests\master\CompatibilityTest.out
M java\testing\org\apache\derbyTesting\functionTests\suites\derbynetmats.runall
M java\testing\org\apache\derbyTesting\functionTests\util\build.xml
A java\testing\org\apache\derbyTesting\functionTests\util\DerbyJUnitTest.java
M java\testing\build.xml
M BUILDING.txt
M build.xml
> 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
[jira] Assigned: (DERBY-516) Need to incorporate client
backward/forward compatibility testing into testing procedures.
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-516?page=all ]
Rick Hillegas reassigned DERBY-516:
-----------------------------------
Assignee: (was: Rick Hillegas)
Unassigning myself since I haven't worked on this issue for a long time.
> 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
> Issue Type: Test
> Components: Test
> Affects Versions: 10.1.1.0
> Reporter: Kathey Marsden
> 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
[jira] Commented: (DERBY-516) Need to incorporate client backward/forward compatibility testing into testing procedures.
Posted by "David Van Couvering (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-516?page=comments#action_12331953 ]
David Van Couvering commented on DERBY-516:
-------------------------------------------
Hi, Rick. I've been looking through your patch, a lot of good work here! Here are my comments/thoughts.
First of all, has anybody besides you run a full compatibility test? I'll do it if I need to, but if somebody's already done it then I don't have to...
testScript.xml
- The standard I have seen in this project is properties in ant are not capitalized. Any particular reason you diverged from this?
- The "embeddedTrunk" target: I don't understand what it means to run a JDBC compatibility test for an embedded engine (which you call an "embedded server" which is confusing). The client and the engine are both in derby.jar -- how can they be incompatible?
- I also noticed that the "jdbcTrunk" target is defined but never used.
JDBCDriverTest:
- I very much like your structure and form in this test. You make solid use of subroutines that are coherent and simple, and it makes the code very readable. That said, you're a little sparse on comments and have a tendency to use obtuse class names like "TD" and "T_CN" and it would be nice if you provided a little more running commentary for the new reader. Comments on your member variables would be great too.
- Way cool comment on COERCIONS, it took me a few mos to realize I had to read top-to-bottom instead of left-to-right (what on earth does
"BBCBCDDDRILLNRSTTVV mean?!") It also helps to read this in a tool that doesn't do auto-word-wrap. You *might* want to explain this for the poor person first reading this... Also explain what this table is for (e.g. yes it can be coerced, not it can't).
- Why do you use "Y" and "_" instead of "T" and "F" or "Y" or "N" for your defines of true and false?. It seems a bit obtuse...
- Is there a reason you check for a boolean return value of your "minion" subroutines rather than have each subroutine throw an exception if it fails? Why are you catching the exceptions in the subroutines and then printing out a message? This way you get no stack trace and the tester has to search for the string in the code. I would much prefer you just throw the exceptions up to the top level and let JUnit report a failure with the message text to help you figure out what's going on.
- I must be missing something, you are only defining valid types for 10.0. Is this because you haven't added the boolean type yet? What will change when you add it? Given the current situation, is there any possibility of getting an incompatibility in your tests, given that all versions support the same types?
- As usual, I like your choice of words, like "firstTastyColumn" and "constructorMinion"
> 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
[jira] Assigned: (DERBY-516) Need to incorporate client backward/forward compatibility testing into testing procedures.
Posted by "Rick Hillegas (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-516?page=all ]
Rick Hillegas reassigned DERBY-516:
-----------------------------------
Assign To: Rick Hillegas
> 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
>
> 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
[jira] Closed: (DERBY-516) Need to incorporate client backward/forward compatibility testing into testing procedures.
Posted by "David Van Couvering (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-516?page=all ]
David Van Couvering closed DERBY-516:
-------------------------------------
Resolution: Fixed
Committed, revision 330139, with a minor fix at revision 330147
> 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
[jira] Updated: (DERBY-516) Need to incorporate client backward/forward compatibility testing into testing procedures.
Posted by "Kathey Marsden (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-516?page=all ]
Kathey Marsden updated DERBY-516:
---------------------------------
Fix Version: (was: 10.1.2.0)
(was: 10.2.0.0)
> 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
>
> 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
[jira] Updated: (DERBY-516) Need to incorporate client backward/forward compatibility testing into testing procedures.
Posted by "Rick Hillegas (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-516?page=all ]
Rick Hillegas updated DERBY-516:
--------------------------------
Attachment: (was: bug516.diff)
> 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
>
> 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
[jira] Commented: (DERBY-516) Need to incorporate client backward/forward compatibility testing into testing procedures.
Posted by "Rick Hillegas (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-516?page=comments#action_12332533 ]
Rick Hillegas commented on DERBY-516:
-------------------------------------
This patch was scraped from a subversion client at revision 325900.
> 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
[jira] Updated: (DERBY-516) Need to incorporate client backward/forward compatibility testing into testing procedures.
Posted by "Rick Hillegas (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-516?page=all ]
Rick Hillegas updated DERBY-516:
--------------------------------
Attachment: bug516.diff
This patch introduces a small JUnit test for checking the compatibility of clients
and servers running at different rev levels and on different vms. This
test initially simply checks that the expected datatypes can be
declared, inserted, selected, and coerced and that they appear as the
correct JDBC types in DatabaseMetaData and ResultSetMetaData.
Please note that when committed, this patch will require developers to
download JUnit so that Derby will build correctly and derbyall will
run cleanly.
The full suite runs correctly on my cygwin platform, testing all
combinations of clients, servers, and vms. Derbyall also runs cleanly,
including a single configuration of the compatibility test.
A brief description of this patch follows:
M tools\ant\properties\compilepath.properties
M java\testing\README.htm
A java\testing\org\apache\derbyTesting\functionTests\tests\compatibility
A java\testing\org\apache\derbyTesting\functionTests\tests\compatibility\README.html
A java\testing\org\apache\derbyTesting\functionTests\tests\compatibility\testScript.xml
A java\testing\org\apache\derbyTesting\functionTests\tests\compatibility\Pinger.java
A java\testing\org\apache\derbyTesting\functionTests\tests\compatibility\JDBCDriverTest.java
A java\testing\org\apache\derbyTesting\functionTests\tests\compatibility\build.xml
A java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\CompatibilityTest.java
M java\testing\org\apache\derbyTesting\functionTests\harness\Sed.java
A java\testing\org\apache\derbyTesting\functionTests\master\CompatibilityTest.out
M java\testing\org\apache\derbyTesting\functionTests\suites\jdbcapi.runall
A java\testing\org\apache\derbyTesting\functionTests\util\DerbyJUnitTest.java
M java\testing\build.xml
M BUILDING.txt
M build.xml
1) BUILDING.txt has been amended to tell developers that they must
download JUnit.
2) java/testing/README.htm has been amended to point at a web page
which describes how to run the compatibility tests. It points at
java/testing/org/apache/derbyTesting/functionTests/tests/compatibility/README.html.
3) DerbyJUnitTest.java is a superclass for Derby JUnit tests. It is a
useful place to put extra assertion machinery not included in the
base JUnit classes.
4) JDBCDriverTest.java is the actual JUnit test which checks expected
datatypes.
5) testScript.xml is an ant harness for running all combinations of
the compatibility test. Hopefully, we can discard this harness when
a more robust JUnit harness is checked into Derby.
6) CompatibilityTest.java is a thin wrapper which runs one
configuration (embedded) of JDBCDriverTest inside the derbyall
suite.
7) Sed.java has been amended to filter out JUnit diagnostics which
derbyall interprets as noise. This filtering allows derbyall canons
to be empty for JUnit tests.
> 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
Re: [jira] Updated: (DERBY-516) Need to incorporate client
backward/forward compatibility testing into testing procedures.
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
Thanks, Rick. I'll test with this new patch. Andrew, FYI, I'm working
on running all the compatibility tests. If these pass, I'm planning on
committing Rick's patch. Let me know if you have any further issues
with his changes.
David
Rick Hillegas (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/DERBY-516?page=all ]
>
> Rick Hillegas updated DERBY-516:
> --------------------------------
>
> Attachment: (was: bug516.diff)
>
>
>>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
>
>
>>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/
>
>
[jira] Updated: (DERBY-516) Need to incorporate client backward/forward compatibility testing into testing procedures.
Posted by "Rick Hillegas (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-516?page=all ]
Rick Hillegas updated DERBY-516:
--------------------------------
Attachment: (was: bug516.diff)
> 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
>
> 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
[jira] Updated: (DERBY-516) Need to incorporate client backward/forward compatibility testing into testing procedures.
Posted by "Rick Hillegas (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-516?page=all ]
Rick Hillegas updated DERBY-516:
--------------------------------
Attachment: bug516.diff
Fix .../tests/compatibility/build.xml to use 1.3 compile classpath rather than generic compile classpath. This should fix the compile problem which Andrew was seeing. That should be the only diff between this and the last rev of the patch. Patch contents are:
M tools\ant\properties\extrapath.properties
M java\build\org\apache\derbyBuild\build.xml
M java\testing\README.htm
A java\testing\org\apache\derbyTesting\functionTests\tests\compatibility
A java\testing\org\apache\derbyTesting\functionTests\tests\compatibility\README.html
A java\testing\org\apache\derbyTesting\functionTests\tests\compatibility\testScript.xml
A java\testing\org\apache\derbyTesting\functionTests\tests\compatibility\Pinger.java
A java\testing\org\apache\derbyTesting\functionTests\tests\compatibility\JDBCDriverTest.java
A java\testing\org\apache\derbyTesting\functionTests\tests\compatibility\build.xml
A java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\CompatibilityTest.java
M java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\build.xml
A java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\CompatibilityTest_app.properties
M java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\copyfiles.ant
M java\testing\org\apache\derbyTesting\functionTests\harness\Sed.java
A java\testing\org\apache\derbyTesting\functionTests\master\CompatibilityTest.out
M java\testing\org\apache\derbyTesting\functionTests\suites\derbynetmats.runall
M java\testing\org\apache\derbyTesting\functionTests\util\build.xml
A java\testing\org\apache\derbyTesting\functionTests\util\DerbyJUnitTest.java
M java\testing\build.xml
M BUILDING.txt
M build.xml
> 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