I checked in IntHandlerUpdateTestCase just now.
It is a sample how I think this should work.

The test case creates a file in /test/db4oVersions/
migrate_int_db4o_6.4.000.yap (I kept .yap, because svn:ignore knows it)

To make this file part of the future version upgrade test in the regression tests:
- remove the .yap from the name
- copy it to all /test/db4oVersions/ places, or fix the logic to use one place only
- add the version name to the #versionNames() array method at the beginning of HandlerUpdateTestCaseBase

Running IntHandlerUpdateTestCase against all the past db4o versions would create all the required files

So the task I am proposing as a first step is to:

(1) create a new project in our SVN where we put all the old db4o jars and .dlls that we want to
create upgradable database files for.
(2) Write either Java code or an Ant task (or whatever) to run from this project that runs the right test cases and produces the database files for each of the old db4o.jar and db4o.dll db4o engines.

If this would be a single Java app, it would use a ClassLoader.

Ant could be easier.

As a result I would like to have migrate_int_db4o_X.x.xxx files for the following db4o versions for Java and .NET:

3.0
4.0
4.6
5.0
5.3
5.4
5.5
5.6
5.7
6.0
6.1
6.3

If you can think of a reproducible easier way to get there, that's fine too.

The script or Java / .NET app should automate producing the database files, so we can repeat, when we have more upgrade test cases completed.