Re: [henshin-dev] Should we introduce a new model version after renaming

[Riegerf@xxxxxxxxxxxxxxxxxxxxxxx]

I'd like to discuss this on a more general level. My main point is  
that we do not know in what way our users might use Henshin, so we  
should not make changes that can break things.

Quoting Christian Krause <henshin.ck@xxxxxxxxx>:
> Thus, I don't want to introduce a new version number.

But changing the model and not introducing a new version number is not  
what I'd call good design. The best approach might be to introduce a  
new version number after *any* alteration of the model, but this will  
of course get excessive and tedious. A good compromise is to keep the  
version number if you only add to the model, thus not breaking any  
form of compatibility. However, if the model is changed in a way that  
could potentially break compatibility, e.g. by renaming, new version  
numbers should always be introduced.
We should figure out a way to trigger migrations in a clever and  
generic way, so that old models can still be used transparently and  
effortlessly. One way to approach this could be to use  
meta-transformations that transform instances of one version of the  
model into instances of the next version.
We only need to figure out once how to integrate this into our tools  
and then we can use a stack of transformations to migrate a model of  
any version to a model of the current version. I would consider this,  
in the long term, to be a much more elegant solution to the problem  
that we have to change the model from time to time.

> It should be fairly simple to fix the existing migration code.

But is it also fairly simple to fix all the other code our users have  
written? If I can write code that will fail with the new version, then  
our users might also run into these problems--and as the model version  
did not change, this will be very confusing and not obvious at all.

But since I'm making a general point here, I don't want to attach it  
to some piece of code; it's a general question of how we should  
approach model changes.

Felix