On 3/19/06, Bryan Pendleton <[EMAIL PROTECTED]> wrote: > Deepa Remesh (JIRA) wrote: > > It should be possible to add more tests using the jar locations for each > > old/new release combination to be tested. > > > > 2. The new master added 'UpgradeTester.out' is based on phaseTester.out > > with few diffs in the statements printed out. > > > > To run upgrade tests using this class, use the command: > > java UpgradeTester <location of old jars> <location of new jars> <old major > > version> <old minor version> > > e.g, java UpgradeTester C:\derby\10.1\lib C:\derby\trunk\lib 10 1 > > If we anticipate that we will eventually have several different upgrade > scenarios and combinations of releases that we desire to support, is it > worth spending a bit of time now coming up with naming conventions > for the master files so that it will be easy to tell them apart? > > That is, should 'UpgradeTester.out' really be named something like > 'UpgradeTester_10_1_10_2.out'? >
Thanks Bryan for looking at this. I have been thinking along the same lines. Here is what I have been thinking: * Use the UpgradeTester class as the common class which can be used to run upgrade test given an old and new release. * Add new classes for each combination similar to what you suggested: UpgradeTester_10_1_10_2. * Remove version specific information from the master file. Do the version checks in UpgradeTester class itself and sed out any version information from the output. * Support testing of upgrade in network client environment. Thanks, Deepa *
