Open question is if this prevents @MichMich from preparing a release?

looking into how he does releases, yes, he uses a PR.

May we could use something like "skipLabels" as provided in the changelog action - or look for a special string in the commit message (which would be not so safe)

may we could use e.g. https://github.com/marketplace/actions/pr-labels to get the PR labels and not exit if a specific label exists.

We need this not only for releases but also for some edge cases as updating README (which is possible after next release without update notifications).

may we could use e.g. https://github.com/marketplace/actions/pr-labels to get the PR labels and not exit if a specific label exists.

I assume we maintainers are the only ones who can add labels to issues @MichMich ? Then adding a label like you say (maybe "hotfix") would be enough I think to prevent future master merges and allow stuff to be merged for such cases

I think there should never be a direct fix to master. always promote from some other branch.
pr to hotfix-x to master,
pr to develop to master

Codecov Report

Merging #3031 (bafa394) into develop (e24dfa6) will increase coverage by 0.07%.
The diff coverage is n/a.

📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more

@@             Coverage Diff             @@
##           develop    #3031      +/-   ##
===========================================
+ Coverage    22.87%   22.95%   +0.07%     
===========================================
  Files           52       52              
  Lines        11541    11541              
===========================================
+ Hits          2640     2649       +9     
+ Misses        8901     8892       -9     

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

So this PR is ready I think. It will complain if the PR is based upon master and does not have the new "mastermerge" label. Maintainers can test it on this PR, just add / remove the label and trigger the tests: #3036

Only thing that doesnt get caught is IF the PR is developed against Develop, but then submitted against Master (thats why this PR here wont fail if I change the base to master). Any ideas on how to fix that or is that a usecase we can ignore?

Any ideas on how to fix that or is that a usecase we can ignore?

I think we can ignore it. If someone has an idea for a fix we can add it later ...