Release process

Steps to perform a release

The following instructions assume that you have sufficient permissions to draft and publish releases.

• If doing a release together with a liboqs release, run python3 oqs-template/generate.py: if code changes become visible, be sure to do a PR with this before the release; be sure to have code properly formatted as per coding style documentation.
• If doing a release independent of a liboqs release, be sure to be able to generate code from the stated supported liboqs release "a.b.c" (by running LIBOQS_BRANCH=a.b.c ./scripts/fullbuild.sh -F && ./scripts/runtests.sh -V).
• Check all CI tests pass.
• Check ./scripts/release-test.sh passes on latest openssl and supported/latest liboqs release(s).
• Update "OQSPROVIDER_VERSION_TEXT" in CMakeLists.txt.
• Update supported liboqs version in CI binary generator files in ".github/workflows" for Linux, MacOS, Windows.
• Open github release UI by clicking on "Releases" and "Draft a new release".
• Select release tag matching contents of OQSPROVIDER_VERSION_TEXT and click "Generate release notes".
• Complete generated notes with high-level release description; do not yet click on "Publish release".
• Copy full release description to the top of RELEASES.md.
• Add and commit this update to main branch (clearing all caches in Actions recommended) assuming you have "maintainer" rights allowing you to merge directly and operate all required github admin interfaces. If you do not have "maintainer" rights, create a PR with your changes targeting main.
• Create and publish a release candidate pre-release in the GitHub release UI with the tag x.y.z-rc1 (e.g., 0.6.1-rc1). "rc1" should be bumped to "rc2", "rc3", etc. if multiple release candidates are required.
• A minimal RC acceptance condition is that nginx and curl images build and interoperate OK (part of automated CI downstream testing).
• When the release candidate is ready for release (usually agreed upon by consensus in an OQS meeting), create and publish the final release.
• After this is done, CI will again trigger downstream creation of integration docker images, e.g., curl and nginx in the oqs-demos sub project. It is highly advisable that the images created at this moment are suitably tagged with the same release version.
• Upgrade "OQSPROVIDER_VERSION_TEXT" in CMakeLists.txt to next "-dev" version for continued development. Either merge directly to main or create a PR targeting main, depending on your permissions. After this has landed, the docker images will be automatically re-created and the specific version matching the release ID will be over-written (unless tagged as per the previous step). Automation for this would be desirable.