TL;DR
- Is runtime model migration planned? Currently we try to keep the runtime models migratable with the model migration tool. We cannot guarantee this for the future, which is why the note in the migration documentation exists.
- Are the existing runtime models bound to their major version? No. An expanded model is still a Document Model, so it can be migrated as one.
- Recommended strategy? Keep a copy of your models, migrate the copy, store the migrated copy, convert it and override the deployed runtime models. Where no copy exists any more, adopt the models you currently have as your source models.
Keep a copy of your models, and run the migration on that copy. The loop for every upgrade is:
- Migrate the copy of the models with the model migration tools.
- Store the migrated copy. It replaces the previous copy and is your source state from now on.
- Run the Workspace Conversion Framework over the migrated copy and override the existing runtime models with the result.
Step 2 is the one that is easy to skip. Store the migrated models, because it is not guaranteed that one tool migrates every model version. If you keep your copy at the version it was originally created with, you have to chain several tool versions on a later upgrade to walk it forward. If you always store the migrated result, one tool run per upgrade is enough.
Where no copy exists any more, treat the models you currently have as the source models from now on, because the expansion produces a Document Model again: the result carries the same model type as its inputs, so it is a valid source for the next model migration. Put them under version control and enter the loop above with them. Note: in this case you may have to strip the __meta groups from the Document Models before step 3, because the Workspace Converters add these groups during the conversion and your adopted models already carry them.
What you do not get back is the modeling time structure. The references to the Type Definition Models and the Includes are resolved and removed by the conversion:
After the model conversion, the Document Model files are self-contained. The references to the modeling time helper models are resolved and removed.
Selection Models and Decoration Models are removed as well, but we assume that these are not heavily used yet, so the practical loss is the Type Definition and Include structure. Therefore I would not invest in reconstructing an original modeling workspace out of the deployed models, because the result is an approximation that you then have to maintain in addition to your generator.
For the dynamic part of your architecture nothing changes structurally. The Workspace Conversion Framework is intended for build pipelines and for model preparation at runtime: generate the source models, run the converter pipeline including your own steps annotated with @WcfConverter, then import the result with importRuntimeModels(InputStream). Persist the generated source models before the conversion, and the question does not arise again for anything generated after the upgrade.
Hint: if you already manipulate the models yourself, it is maybe interesting to move that manipulation into the Workspace Conversion Framework as your own converters, so you use its functionality instead of maintaining your own pipeline around it.
Keeping the runtime models migratable is our current intention, not a commitment. The safe path stays the copy of your source models. If you still have questions or would like an individual consulting on your setup, please get in touch with us.