Release process

The following files are to be updated

• The top-level CMakeLists.txt: Update the OQS_VERSION_TEXT variable.
• RELEASE.md - Update version number, fill in text

After a release candidate passed all internal and downstream project tests, downstream projects should also be tagged, too.

Most notably, constant time tests need to be executed locally without skipping any algorithms (as is done to allow CCI task weekly to pass), i.e., run python3 -m pytest --verbose --numprocesses=auto tests/test_constant_time.py after building liboqs via cmake -GNinja -DOQS_OPT_TARGET=haswell -DCMAKE_BUILD_TYPE=Debug -DOQS_ENABLE_TEST_CONSTANT_TIME=ON ...

For subproject openssl a specific release-test script should be run on a suitably powerful (many-core) machine: It enables all algorithm combinations and tests those.

Docker images resulting from the build in oqs-demos should be tagged to the same version number as liboqs as and when they have been built and deployed by the CCI automation. Sample command: docker tag openquantumsafe/curl:latest openquantumsafe/curl:0.5. The binary image of chromium has to be built in a bespoke ubuntu image with all prerequisites as documented. Be sure to set -DOQS_DIST_BUILD=ON to execute the resultant binary on any CPU. There presently is no docker-based build infrastructure available to generate and test-run this binary.

Subsequent a successful new release, follow the documentation at oqs-demos/nginx/fulltest to install a new interop test server. Possible procedure:

• Update version tags of liboqs and oqs-openssl in build-ubuntu.sh
• build server and certificates
• deploy to actual server All three steps could be performed at once when executed at the configured test server (test.openquantumsafe.org).

The benchmarking image is presently not automatically built at each merge to (OQS-OpenSSL or liboqs) main, so the build task in oqs-profiling should be manually triggered, e.g., by a version bump in the project's README, if a new liboqs release has been done.