Version 3.11.1 retrospective

[nlohmann]

Pain points

• The 3.11.0 release had a bug that broke existing builds. This can happen, but was unfortunate as a new release had to be prepared on short notice.
• The release script was changed for 3.11.0 and apparently did not work fully. As a result, the master branch of the repository was removed and the git-flow checkout script did not work until a new master branch was created.
• We have no playbook what to do if an announced release contains a breaking bug. As first aid, I added a comment to the release notes stating that the release is buggy and later linked the newer release - I still expect a lot of upcoming support requests down the road.
• The slow CI blocked "important" branches to be checked with priority. I had to manually cancel running builds to quickly get the fix through.

Possible improvements

• Be more vigilant to wide-spread changes to the test suite. The breaking change would have been detected if the test suite had not been changed at the same time as the library code.
• Git-flow may not be the best model for the release - usual development does not follow this model, so using it for the release is arbitrary. All in all, we just need to make sure that the daily development (aka "bleeding edge") happens in develop and master always has the latest release.
• We should define a strategy what to do in case a release is buggy.

[falbrechtskirchinger]

I just finished my own post-mortem.

I created one commit for the documentation, one for CMake, and none for the actual code – *sigh*.

Usually, I do my own review on GitHub and catch many issues that way. I didn't this time.

Going forward, I'll review and approve my own PRs – that then signals to you, that I've done my due diligence. Maybe it's a good idea to ask that of everyone. People may just rubberstamp their own PRs, but it's not meant as a substitute for an independent review anyway.