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 Rick Hillegas <Ri...@Sun.COM> on 2005/09/01 02:25:12 UTC
client/server compatibility testing
Here are some musings about testing the compatibility of clients and
servers across Derby versions and supported platforms.
Our servers need to interoperate with the following clients:
Derby 10.2
Derby 10.1
Derby 10.0
db2jcc
In turn, these clients need to interoperate with the following servers:
Derby 10.2
Derby 10.1
Derby 10.0
Our clients and servers are platform sensitive . Based on the platform,
a client/server supports some JDBC rev level. I don't know about the
platform sensitivity of the db2jcc client. The supported platforms are:
jdk1.3
jdk1.4
jdk1.5
jdk1.6
NumberOfClients * NumberOfClientPlatforms * NumberOfServers *
NumberOfServerPlatforms = 192. This is a lot of combinations in which to
run a compatibility test suite. If the suite becomes fairly
comprehensive, you could imagine it taking 5 minutes to run. That's 16
hours for all combinations. It would be too burdensome to require all
combinations as part of the checkin barrier. The following sounds
reasonable to me:
o As part of the checkin barrier, derbyall should just test the
compatibility suite against a Derby client and server running at the
current level on the same jdk version.
o The full set of combinations can be run on a weekly basis by some
authority.
o The full set of combinations should be run as part of the release barrier.
Comments? Improvements?
Thanks,
-Rick
Re: client/server compatibility testing
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Rick Hillegas wrote:
[snip]
> o The full set of combinations can be run on a weekly basis by some
> authority.
Well, I would replace 'authority' with 'interested person(s)'.
> o The full set of combinations should be run as part of the release
> barrier.
There's no such a thing as a 'release barrier'. Maybe re-word to
something like 'Having individuals running & reporting combinations
would provide useful information for a release.'
Dan.
Re: client/server compatibility testing
Posted by Kathey Marsden <km...@sbcglobal.net>.
Rick Hillegas wrote:
> Here are some musings about testing the compatibility of clients and
> servers across Derby versions and supported platforms.
Thanks Rick for thinking about this testing ! Just a couple notes on
client.
>
> Our servers need to interoperate with the following clients:
>
> Derby 10.2
> Derby 10.1
> Derby 10.0
> db2jcc
>
There is no Derby10.0 client.
> In turn, these clients need to interoperate with the following servers:
>
> Derby 10.2
> Derby 10.1
> Derby 10.0
The 10.0 server is not supported with client.
Re: client/server compatibility testing
Posted by Suresh Thalamati <su...@gmail.com>.
With the new proposal on the list to port some fixes to the old
versions. Is it really necessary to support all these
combinations? especially, what is the need for new client driver
to work with the old version of the servers?
May be, I am missing something!
Thanks
-suresht
Rick Hillegas wrote:
> Here are some musings about testing the compatibility of clients and
> servers across Derby versions and supported platforms.
>
> Our servers need to interoperate with the following clients:
>
> Derby 10.2
> Derby 10.1
> Derby 10.0
> db2jcc
>
> In turn, these clients need to interoperate with the following servers:
>
> Derby 10.2
> Derby 10.1
> Derby 10.0
>
> Our clients and servers are platform sensitive . Based on the platform,
> a client/server supports some JDBC rev level. I don't know about the
> platform sensitivity of the db2jcc client. The supported platforms are:
>
> jdk1.3
> jdk1.4
> jdk1.5
> jdk1.6
>
> NumberOfClients * NumberOfClientPlatforms * NumberOfServers *
> NumberOfServerPlatforms = 192. This is a lot of combinations in which to
> run a compatibility test suite. If the suite becomes fairly
> comprehensive, you could imagine it taking 5 minutes to run. That's 16
> hours for all combinations. It would be too burdensome to require all
> combinations as part of the checkin barrier. The following sounds
> reasonable to me:
>
> o As part of the checkin barrier, derbyall should just test the
> compatibility suite against a Derby client and server running at the
> current level on the same jdk version.
> o The full set of combinations can be run on a weekly basis by some
> authority.
> o The full set of combinations should be run as part of the release
> barrier.
>
> Comments? Improvements?
>
> Thanks,
> -Rick
>
>
Re: client/server compatibility testing
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
All I can say is we are lucky we don't have to worry about ports to
different platforms! I remember Sybase had a 5-person team working on
this full-time, it took them about 6 months to set up a framework just
to run basic "ping" tests across all the different combinations.
David
Rick Hillegas wrote:
> Here are some musings about testing the compatibility of clients and
> servers across Derby versions and supported platforms.
>
> Our servers need to interoperate with the following clients:
>
> Derby 10.2
> Derby 10.1
> Derby 10.0
> db2jcc
>
> In turn, these clients need to interoperate with the following servers:
>
> Derby 10.2
> Derby 10.1
> Derby 10.0
>
> Our clients and servers are platform sensitive . Based on the
> platform, a client/server supports some JDBC rev level. I don't know
> about the platform sensitivity of the db2jcc client. The supported
> platforms are:
>
> jdk1.3
> jdk1.4
> jdk1.5
> jdk1.6
>
> NumberOfClients * NumberOfClientPlatforms * NumberOfServers *
> NumberOfServerPlatforms = 192. This is a lot of combinations in which
> to run a compatibility test suite. If the suite becomes fairly
> comprehensive, you could imagine it taking 5 minutes to run. That's 16
> hours for all combinations. It would be too burdensome to require all
> combinations as part of the checkin barrier. The following sounds
> reasonable to me:
>
> o As part of the checkin barrier, derbyall should just test the
> compatibility suite against a Derby client and server running at the
> current level on the same jdk version.
> o The full set of combinations can be run on a weekly basis by some
> authority.
> o The full set of combinations should be run as part of the release
> barrier.
>
> Comments? Improvements?
>
> Thanks,
> -Rick
>