Proper handling of library versions in OMEdit

[Francesco Casella]

The current handling of library versions in OMEdit is quite limited. If a package is opened that has a uses annotation, and the used library is installed in the modelicapath, then it is loaded automatically. However, all kinds of version conflicts are not handled at all, the user just gets this message:

Scripting Warning: Requested package NNN of version x.y.z, but this package was already loaded with version a.b.c. You might experience problems if these versions are incompatible.

which belongs to the category of the error messages that may scare off inexperienced users, who may wonder: what problems, and, what can I do about it?

In particular, the latest version of MSL is pre-loaded in OMEdit, which is a good idea if one wants to start a new project, but may lead to problems if one is using code that requires an older version for any reason.

MSL 4.0.0 is planned to be rolled out in one year, and it will not be backwards compatible, thus requiring conversion scripts. We may expect that for some time people may want to keep on using MSL 3.2.3, so by that time, we need to have a comprehensive user-friendly solution in place.

This is a first sketch of the user requirements, but I think we should iterate on it until we find it completely satisfactory.

• OMEdit preloads the latest version of the MSL at startup (or a previous version, if specified in the OMEdit setup, this could be handy during the MSL 4.0.0 transition).
• When a package is loaded that uses a previous version of an already loaded package (including the MSL), a dialog should be provided with the options of
  • unload the current version of the used library and load the older one instead, either from modelicapath, or by opening a file
  • update the loaded library to the current version of the used library, running conversion scripts if necessary (see #5297)
  • keep using the current library without updating the loaded library (assuming you know what your're doing, do it at your own risk).

This mechanism should work consistently even in the case of multiple dependencies; for example, if I first load library A that requires MSL 3.2.2 and I decide to load that instead of MSL 3.2.3, if I then load library B that wants 3.2.3 instead we can't just unload MSL 3.2.2, because that would break library A. I still don't know exactly what is the best way to handle these situations, I guess we should brainstorm a bit.

In case the conversion ( noneFromVersion = VERSION-NUMBER) is present, the dialogs should make it clear that the conversion requires no changes and it should not generate issues. The presence of conversion scripts, once supported, should be notified, and we may suggest the user to check the library release notes for news about the updates.

It would be nice if the version annotations contained library-specific information about the conversion, maybe we should make this proposal to the MAP-LANG group.

[leo.gall@…]

When using a newer version of OpenModelica, the cited warning struck me, as well! "If these versions are incompatible". How would I find this out?

Some comments from my side:

1. Conversion wont fix all strange changes for users. Therefore: No user wants to do it, but unfortunately it's the only way to find out about critical changes due to bug fixes: Read release notes. Would there be a way to automatically link to the release notes in User's Guide?

2. While I like the idea of "load old stuff", I think it is important to guide users to converting to the newest possible library. Incremental conversions are easier than one big conversion, when you are finally trapped in verison dependency hell.

3. Sidenote: Just to complicate things, there is also a dependency on Modelica language versions. This is usually ignored, because we don't know which language version was used when building a library (MCP-0015: Language Version ​#1726).

4. Conversion and upgrading is generally scary to end users. If you do not store your models in a revision control system, you have no clue what the Modelica tool did change in your models. A good logging of changes would be crucial.

Related MAP-LANG tickets

• ! MCP-0016: Semantic Versions for Libraries ​#1728
• Clarifications for MCP-0014: automatic conversions of models ​#2178
• library dependencies ​#556
• Package improvements ​#573
• ! Uses annotation should support mutliple libraries ​#1023 -> I thought this has been resolved? No? Francesco and myself should push for this in one of the next Modelica Design Meetings.
• ! Package Dependency Resolution ​#1618 -> does prerequisite 1. hold in Francesco's scenario?
• Library Distribution Protocol ​#536
• Distribution of Modelica libraries - Modelica Archive proposal ​#1152

I think it's currently very hard for Modelica tools to do a good job, because the language is missing crucial features for library developers, so they could define "compatibilty regions" or "supported/tested combinations of libraries".
Think about Buildings Library: if the next version could state "I'm compatible with MSL 3.2.2 and 3.2.3" then OpenModelica could load MSL 3.2.3, open Buildings library and automatically convert a user package to MSL 3.2.3. In this case, it would not be perfect to stick to MSL 3.2.2.

[Francesco Casella]

I wholeheartedly subscribe to 100% of Leo's observations :)

Thanks for posting comment:3