[OMCSession*] renames

[syntron]

based on top of PR #381

• rename OMCProcess* classes to OMCSession* classes
• rename omc_process to session
• cleanup docstrings

[adeas31]

We added OMCProcess* classes in 4.0.0 and then renaming it to OMCSession* classes in a sub-release doesn't sound like a good idea. I thought the refactoring was mostly targeted for 5.0.0

[syntron]

@adeas31 you have a good point here; however, I think that this change should be added to 4.1.0 as an update of the changes done in 4.0.0. Reasoning: I never planned to make it more complicated for the users (2 types of classese to handle). However, at the time for 4.0.0 I had no idea how the two tasks: (1) setup connection to OMC and (2) provide the interface via sendExpression() could be implemented in one class. Here, we have a solution via the __post_init__() functionality.

Again, I would like to see this as an update to the changes in 4.0.0 with the main changes (removing of compatibility layers) to be done in 5.0.0. This also takes into account, that I expect that the amount of updates will go down in the next weeks / months and thus it could be a longer time till a version 5. OMPython now has a quite good code base!

[casella]

If we stick to semver, minor releases should not change the interfaces, that's reserved for major releases (5.0.0 in this case).

[adeas31]

If we stick to semver, minor releases should not change the interfaces, that's reserved for major releases (5.0.0 in this case).

I agree.

@adeas31 you have a good point here; however, I think that this change should be added to 4.1.0 as an update of the changes done in 4.0.0. Reasoning: I never planned to make it more complicated for the users (2 types of classese to handle). However, at the time for 4.0.0 I had no idea how the two tasks: (1) setup connection to OMC and (2) provide the interface via sendExpression() could be implemented in one class. Here, we have a solution via the post_init() functionality.

I understand but we did what we thought was best, unfortunately that ended up as extra work for users.

Again, I would like to see this as an update to the changes in 4.0.0 with the main changes (removing of compatibility layers) to be done in 5.0.0. This also takes into account, that I expect that the amount of updates will go down in the next weeks / months and thus it could be a longer time till a version 5. OMPython now has a quite good code base!

We can release 4.1.0 with minimum changes/fixes. As soon as 4.1.0 is release we can start with renaming/restructuring of interfaces which can go in release 5.0.0. And this means that the removal of compatibility layers can go in 6.0.0.

[syntron]

@casella I understand your reasoning and will check if I find a solution which keeps the (public) interface stable

However, some changes after 4.0.0 changes the public interface in relevant ways:

• PR OMCPath #317 (and PR [OMCProcess*] use pathlib #332, ModelicaSystem - use OMCPath #322) - definition of OMCPath and use of it for OMCSessionZMQ and ModelicaSystem
• PR [OMCSessionRunData] run executable via OMCSessionZMQ #331 - run executable not in ModelicaSystemCmd but in OMCSessionZMQ; additional (important) parameter added to ModelicaSystemCmd
• PR ModelicaSystem update __init__() #350 (for PR [ModelicaSystem] make convertFmu2Mo() useable #351) - rewrite of init() for ModelicaSystem; move parts to ModelicaSystem.model()

Especially the last one is a major change of the interface; here, I did not account for the users of OMPython which rely on a stable interface but pushed for updated code. If taking semver seriosly, this alone would require a version 5.0.0 :-(

[adeas31]

PR #350 already changes the interface (see my comment: #350 (review)).

One solution is to go directly for 5.0.0 and skip 4.1.0 altogether to stay consistent with semver. What do you think?

[syntron]

I'm fine with any of these options; going for 5.0.0. would make life easier as I do not have to keep track of some changes locally ...