MSL v4.1.0-beta.1 feedback on asset structure

[beutlich]

This is the library structure of https://github.com/modelica/ModelicaStandardLibrary/releases/download/v4.0.0-beta.1/ModelicaStandardLibrary_v4.0.0-beta.1.zip

- Modelica 4.0.0/
- ModelicaReference 4.0.0/
- ModelicaServices 4.0.0/
- ModelicaTest/
- LICENSE
- README.md
- Complex.mo
- ModelicaTestConversion4.mo
- ModelicaTestOverdetermined.mo
- ObsoleteModelica4.mo

and this is how it looks in https://github.com/modelica/ModelicaStandardLibrary/releases/download/v4.1.0-beta.1/ModelicaStandardLibrary_v4.1.0-beta.1.zip

- ModelicaStandardLibrary-maint-4.1.0/
  |- Modelica/
  |- ModelicaReference/
  |- ModelicaServices/
  |- ModelicaTest/
  |- Complex.mo
  |- LICENSE
  |- ModelicaTestConversion4.mo
  |- ModelicaTestOverdetermined.mo
  |- ObsoleteModelica4.mo
  |- README.md

Two obvious issues here:

1. The top-level directory ModelicaStandardLibrary-maint-4.1.0\ is not needed.
2. The library directories miss the version suffix. Not sure if needed, but for now it is not consistent with what's documented at https://github.com/modelica/ModelicaStandardLibrary/wiki/Generating-a-new-MSL-release.

[henrikt-ma]

Two obvious issues here:

1. The top-level directory ModelicaStandardLibrary-maint-4.1.0\ is not needed.
2. The library directories miss the version suffix. Not sure if needed, but for now it is not consistent with what's documented at https://github.com/modelica/ModelicaStandardLibrary/wiki/Generating-a-new-MSL-release.

Consistency with what's documented is good, but perhaps it's the documentation that needs to be updated? To me, the new packaging looks better than the old one:

• The old way of putting the version number in a directory with a package.mo inside was against the specification: https://specification.modelica.org/master/packages.html#directory-hierarchy-mapping
• It is very convenient to have the version present in the directories on the MODELICAPATH, especially when having multiple versions installed at the same time, and the new distribution with a single top level directory for the library solves this nicely. (It's a pity that https://specification.modelica.org/master/packages.html#the-modelica-library-path-modelicapath doesn't mention this need.)
• Files such as LICENSE and README.md clearly doesn't fit directly on the "modelica path", so with the previous distribution one would need to create a suitable directory for the contents anyway.

[maltelenz]

• The old way of putting the version number in a directory with a package.mo inside was against the specification: https://specification.modelica.org/master/packages.html#directory-hierarchy-mapping

Not true: https://specification.modelica.org/master/annotations.html#mapping-of-versions-to-file-system

[henrikt-ma]

Not true: https://specification.modelica.org/master/annotations.html#mapping-of-versions-to-file-system

OK, so it wasn't that strange that it looked so familiar after all. Looks like it's time to update Directory Hierarchy Mapping then.

[beutlich]

Consistency with what's documented is good

Indeed, that's all what I am aiming for. We should at least stick with our own documentation and guidelines.

[casella]

@beutlich, @arunkumar-narasimhan, it is not clear to me if these assets were created manually or automatically. https://github.com/modelica/ModelicaStandardLibrary/wiki/Generating-a-new-MSL-release explains both how you can do it manually or automatically. Can we make sure that the forthcoming MSL 4.1.0.rc.1 (and the subsequent final release) follow the structure detailed in https://github.com/modelica/ModelicaStandardLibrary/wiki/Generating-a-new-MSL-release?

Thanks!

[beutlich]

I used the manual workflow to create the release asset.

[beutlich]

There is no MSL release asset available for v4.1.0-beta.2.

[casella]

We had a discussion about this during the MAP-Lib meeting today. Basically

• all tool vendors take the MSL source code from the GitHub repo, either via git clone or by getting the automatically generated zip file with all the repo contents
• "regular" end users are not expected to install MSL on their own, but rather to rely on MSL provided by their tool vendors

BTW, starting from the next versions, the GitHub repo will be deliberately missing the binaries, which are meant to be generated by each tool vendor in a tool-optimal way. That decision was taken long time ago, see #4347.

So, there's probably no need to provide such curated assets.