Release cycle of MSL

[AHaumer]

Some time ago we discussed the release cycle of the Modelica Standard library.
It seems that we are making no progress (latest release: 4.0.0, 2020-06-04).
That means, we have for 1 1/2 years no new release.

When during everyday's work with students I stumble upon a model or block that is missing in MSL or that could be improved, I create a PR. But having the new or improved model "at your fingertips" (i.e. in the latest MSL delivered with your simulator) takes too long. You have to store a copy of the model that eventually is included in the MSL at some time in future, and keep this copy aligned with the PR to continue with your work and keep your work compliant with future versions of MSL.

Even worse: We have PRs that are not reviewed for a long time.
Of course discussion about a PR is highly appreciated, but getting no review is demotivating.

What could we do, what should we do to improve the situation?

[sjoelund]

What could we do, what should we do to improve the situation?

We'll need leadership for MSL. The position has been vacant, with the MA chairman not having the time necessary to do the work and formally being in charge.

[beutlich]

Not only the new main (major or minor) release v4.1.0 or v5.0.0 needs to be considered, but the maintenance releases v4.0.1 and v3.2.3+build.5 are undecided, too. I backported most of the commits to these two maintenance branches, but wonder if it is necessary at all if there never will be any new maintenance release in the future. @MartinOtter

[beutlich]

but the maintenance releases v4.0.1 and v3.2.3+build.5 are undecided, too. I backported most of the commits to these two maintenance branches, but wonder if it is necessary at all if there never will be any new maintenance release in the future.

This was answered today by @casella:

Regarding the MSL4.0.1 milestone, there were 27 merged PRs there, which were all back-ports from master (I checked them one by one, just in case). Since we are not going to release 4.0.1, I just closed that milestone.

I guess, similar reason holds for v3.2.3+build.5, which means there no longer is a need to back-port bug-fixes (i.e., PRs with the bug label) to these two "maintenance" branches (as it was originally designed).