liboqs release schedule

[thomwiggers]

Starting from @baentsch's comment in #910 I think it would be good to consider releasing 0.5 soon (probably after merging #900). However, in general it might be a good idea to consider speeding up the release schedule: just churn out a release every so often (frequently), following semver, so whenever a breaking change occurs (KATs, schemes deleted) we bump the version. This would hopefully help people not need to run off main as much.

This would hopefully make it a bit more clear for downstream users like @david415 what versions are compatible etc and if they need interop with something, if we need to merge breaking changes like #900 then a semver bump would indicate that users can expect breakage.

This would especially benefit wrappers like the Rust crate as well :)

(I appreciate that I might have completely missed a lot of discussion and concern that have been raised in the weekly meetings)

[baentsch]

However, in general it might be a good idea to consider speeding up the release schedule

Absolutely agree. If that were the case/goal we could also consider not building as part of the CI cycle "heavyweight" artefacts likeprofiling or oqs-demos, but only when a release is done -- which in turn again would make CI faster and allow quicker cycles.

[thomwiggers]

It should be fairly easy to set up such things as triggered by tags.