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
