[henshin-dev] Technical details for Henshin model migration

[Christian Krause <henshin.ck@xxxxxxxxx>]

Hi everybody,

version 0.9.0 will introduce changes in the Henshin model which will 
break back-forward compatibility. Currently, we have two problematic 
changes:

* attribute NestedCondition.negated will be removed
* class AmalgamationUnit will be removed

Therefore we need to come up with a user-friendly solution for migrating 
0.8.0 models to 0.9.0 models.

To distinguish between the two versions we will change the namespace URI:

* version 0.8.0: http://www.eclipse.org/emf/2010/henshin
* version 0.9.0: http://www.eclipse.org/emf/2011/henshin  (or 2012)

The question is how we migrate the existing 2010-models. Here is one 
idea which could work:

We change the namespace URI of the generated code to 2011/12. We keep an 
old version of the model file and name it, say, henshin-2010.ecore. We 
register the old model dynamically (no generated code).

Now for the migration: We could transparently translate old models when 
they are being loaded. For this, we change the resource implementation 
(HenshinResource) such that whenever an old model is loaded (the dynamic 
classes), it is automatically replaced by the new version of the model. 
We would have to translate every dynamic class by its corresponding 
generated class (the new version).

To incorporate the changes, we would do the following:

* If we find a 2010-version of NestedCondition which has the attributed 
"negated" set to true, we wrap the generated instance in a "Not".

* If we find an AmalgamationUnit we do not create a corresponding new 
element for it. Instead, we add the multi-rules and multi-mappings 
directly to the generated version of the kernel rule.

The approach has pros and cons:

pro: easy to implement; users will not be bothered with migrating their 
model; in, say, 95% of the cases no problem should occur; the old 
version of the model will only be overridden on disk when the user saves 
the model again

con: the user might be surprised when the AmalgamationUnits suddenly 
disappear. there can be cases where the automatic migration can fail. 
but this is also true for other solutions.

Please comment.

Ciao,
Christian