Package documentation for org.apache.derbyTesting.functionTests.tests.compatibility

Classes used to test the compatibility between different versions of Derby clients and Derby servers. The main entry point is the `_Suite` class, with the other suites as alternatives giving more test coverage in terms of the number of combinations tested.

The MATS version of the compatibility test should be run as part of `suites.All`. It is your responsibility to keep the local release repository up to date (the default location is `$HOME/.derbyTestingReleases/`, this can be overridden by using `derbyTesting.oldReleasePath`).

For non-default runs, the following steps should be considered:

1. Update the release repository (typically a `svn up`)
2. If you want to run the LOB tests, set `derby.tests.compat.testLOBs` to `true`. Note that this will add around five minutes of runtime to each combination
3. If you want to include only a specific set of releases, set `derby.tests.compat.includeReleases`. The format is `M.m.f.p[,M.m.f.p]*`, for instance `10.9.1.0,10.8.2.2`.
4. If you want to exclude certain releases, set `derby.tests.compat.excludeReleases`. The format is the same as for the include option above.
5. Run the suite that best fits your needs; MATS, dev full, old, or old full.

Note that the set of combinations computed depends on the old Derby releases that are available through the release repository. For this reason it is important to keep the local repository updated. Once initialized, i.e `svn co http://svn.apache.org/repos/asf/db/derby/jars $HOME/.derbyTestingReleases`, you only have to update it each time a new Derby release comes out.

Testing the compatibility between a given client driver and a given server is best done by running those two components in separate processes. This simplifies handling multiple versions of the code base, but introduces some challenges for properly handling the external processes.