Language Migration

Hi,
We are currently developing a new framework for migrations, that will allow to perform broader variety of tasks than the current one. It will be available in 3.2, which we plan to release at the end of this year.
Now about your questions, answering both for the old and new systems:
1) In old system, this "build number" is only used for grouping scripts in tools->scripts menu, so just place _your_ product's (e.g. your language's) version there. In new system, there will be a "version of a language" field, and it will be set automatically (language version will be tracked everywhere)
2) In old system, scripts are not applied automatically, the user should run them all from the tools->scripts menu. In new system, MPS will notify user on project open about migrations that should be run on his project. The user can run them "just now" or "later". Anyway, he'll be notified again and again until he applies all the migrations.
3) Both in the old and in the new systems, you provide a migration script, which gets all nodes<A> and transforms their children of concept C into new nodes of concept B. E.g.

node<A> myNode = <initialized previously>;
node<C> oldChild=myNode.myChildC;
node<B> newChild = oldChild.replaceWith(new node<B>);
newChild.innerChild = oldChild;

Regards,
Mihail

Hi, Mihail. When migrated, is language of older version gets replaced with language of new versions among all affected models?

Hi Mihail,

thank you very much for your response and sorry for my delayed reply. I've been very busy the last week. I will try your solution asap.

Regards,
Lars

Also, is web version of MPS going to inherit codebase of current MPS? I mean, all new stuff, will it be there in web-based MPS?

Askar,
It seems my previous post was quite unclear. So, I'll try to explain what we are currently working on in migration framework.

Actually, MPS will NOT support different versions of language working in the same instance. There will be only one instance of each language. The old structure elements should be kept in the language at least in structure aspect.

For example, if you'd like to refactor concept's reference (replace it with another ref plus a property), you keep the old one (deprecate it) and create a new (migrated) one. You can remove all the supporting code for the old reference (typesystem, editor, generator), but should keep the ref itself in structure model. After it, you write a "migration", which migrates the old ref to a new one, and it works perfectly fine as both the "old" and "migrated" states of the AST become valid ones as we keep the old stuff in language's structure.

The "language version" here means that each migration will be associated with a specific state, in which the language was at some moment. When migrating models, the language versions will be tracked, which guarantees that if you wrote two migrations (M1 and M2) in some language, M1 will be executed before M2, so that user's model will never be in a state, which wasn't allowed at any time of language's existence (this would happen if we executed M2 before M1).

So, as the migrations are applied to models, the "language version" in those models increase for the corresponding languages, and this means all the AST constructions that had to be migrated, were migrated. This will happen for each model in a project, which uses the language with a migration written.

Anyway, you'll be able to try all these soon; we suppose to make a public EAP in a couple weeks )

Though I'm not into this project, I wouldn't say from what I know that it will be "web-based IDE". If you are asking about migrations, it seems to me, that they are not needed there.
But I might be wrong.
Some code will be shared, for certain

Mihail, thank you for your explanation. I really had another versioning model in my mind, which indeed is a bit complicated both to use and to maintain, and you suggest Java-like source versioning instead.