Update library to MSL 4.0
bernhard-thiele opened this issue · 4 comments
MSL 4.0.0 is soon to be released.
Updating MDD to run smoothly with MSL 4.0.0 (e.g., using Modelica.Clocked instead of Modelica_Synchronous) will loose backwards compatibility to MSL 3.x. Hence. we will need to increase the version number to MDD v2.0.0 according to semantic versioning conventions.
A quick test with MDD showed that the automatic conversion scripts from MSL 3.x to 4.0 work, so updating MDD to use MSL 4.0 seems easy. My Dymola Version 2021 Beta 3 generates following conversion script for updating the MDD master to MSL 4.0.0.
// Generated by conversion of Modelica_DeviceDrivers
convertElement("Modelica_DeviceDrivers.Blocks.Examples.TestHardwareIOComedi","sine.freqHz","sine.f");
convertElement("Modelica_DeviceDrivers.Blocks.Examples.TestHardwareIOComedi","sine1.freqHz","sine1.f");
convertElement("Modelica_DeviceDrivers.ClockedBlocks.Examples.TestHardwareIOComedi","sine.freqHz","sine.f");
convertElement("Modelica_DeviceDrivers.ClockedBlocks.Examples.TestHardwareIOComedi","sine1.freqHz","sine1.f");
convertElement("Modelica_DeviceDrivers.Incubate.Bustesting.TestTheBus","comp1_1.sine.freqHz","comp1_1.sine.f");
convertElement("Modelica_DeviceDrivers.Incubate.Bustesting.Comp1","sine.freqHz","sine.f");
The conversions are only in the MDD examples, not in the components. Hence, we probably don't need to deliver a conversion script.
Since we loose backwards compatibility to previous MSL 3.x versions anyway, we can also change some code to use newer blocks, e.g. the Modelica.Icons.FunctionsPackage icon which we have avoided so far.
Mentioning @tbeu so that you are aware of this issue.
I will also update paho.mqtt.c soon again. Will there be different branches for MSL 3 and MSL 4 dependency?
I think we should fully move to MSL 4 for new features, because otherwise maintenance efforts increase a lot. Maybe if there is bad bug which plagues people who need MSL 3 we can do another MSL 3 based bugfix release, but otherweise v1.8.2 would be the last MSL 3 release.
However, maybe it's a good idea to create an MSL 3 branch before merging #317. What name should it have? Maybe maint/msl3. What are your thoughts?
Having a maint/1.8.x branch branching off from 6124766 (= v1.8.2) would be my first preference. If you however plan to have a v1.8.3 release anyway, we can branch off from current HEAD. But I agree, maintenance effort should be kept minimal.
Okay, that sounds good. I created the maint/1.8.x branch and will merge #317 next.