I have spent some time following the debugger through a migration process, and have a much clearer picture of what is happening.

I do have a couple of new questions, though. (sorry!)

On a conceptual level, I am not sure about the difference between a Change executed in the EMF editor and recorded in the history, and an operation that does the same thing ( delete a class, for example ).

Both seem to implement their behaviour with a call to metamodel.delete(eClass), but one executes from the EcoreForwardReconstructor, and one from the MigrationReconstructor.

Is this a matter of preference when to use which one?

The second concerns the API. I can use either migrateAndSave or migrateAndLoad on a Resource level. Unfortunately, most of our migration is done on export, i.e. starting from EObjects in memory or on parts of the model only.

I can see why there is this limitation. As far as I understand, the model to migrate needs to conform to a reconstructed source metamodel that will be destructively migrated alongside the model to a different release.

However, in between loading and saving there seems to be a conversion from DynamicEObjectImpl to InstanceImpl, which appears to be a different Implementation of EObject that also provides access to all instances of an EType. The new InstanceImpl replace references to model EObjects with references to the corresponding InstanceImpl, but keep a reference to the metamodel.

It seems not too difficult to provide an alternate creation mechanism for such an Instance model that takes a model from a different ( possibly generated ) EPackage, but replaces the metamodel references with references to the reconstructed metamodel. With such a hook we could probably cover most of our requirements.

This would require some opening up on the API side, though. Is this something that could be considered?

If not, I suppose it would be possible to save/load the resources everytime a migration needs to be done, but I am concerned over memory ( and perm space ) usage due to all the model duplication. Our metamodel is huge, and model xmi files can grow to several hundred MB.

A third question is about the release ordering. In the release menu there is a Label to Match field. Does this mean that releases do not need to be chronologically ordered, or even part of the same sequence? Is it possible to have some versions branch off/specialise within the same history file?

Finally, I stumbled accross a class called EcoreBackwardReconstructor which is unused, but seems to be a good starting point for reverse history. Is there something similar for the MigrationReconstructor?

I have some ideas how to implement a reverse migration scheme on operation or reconstructor level, but I have no clue how and where to start looking at a reverse history generation. Do you have a few hints on good starting points?