Evolving your language gracefully

When you make changes to language concepts, make them backward-compatible. Don’t remove anything right away. Instead, deprecate features and make them optional first. Remove them when they have been deprecated for a while and the users have migrated not only their master branch but any work-in-progress they may have on other branches.

Until you remove them, leave the deprecated features in the editor. Show them conditionally (show if), only when they have a value. In that case also show a warning text that a migration should be run. I like to make it red and bold.

With this approach, if your users accidentally merge old code into new code, they will easily notice the outdated code and your warning will tell them what to do about it.

For your users it is also much easier to delete the deprecated nodes in the normal editor than resorting to the reflective editor or MPS Console.

If you need to be more strict, add a checking rule to make sure the deprecated fields are empty, and run the model checker regularly.

And make sure your migrations are re-runnable (idempotent): assume that any node you are trying to migrate may have been already migrated before and deal with it gracefully.