Making a release
Last updated
Last updated
This document explains how Zama people can release a new version of Concrete.
All releases should be done on a release branch: our release branches are named release/MAJOR.MINOR.x (eg, release/2.7.x):
either you create a new version, then you need to create the new release branch (eg, the previous release was 2.6.x and now we release 2.7.0)
or you create a dot release: in this case you should cherry-pick commits on the branch of the release you want to fix (eg, the previous release was 2.7.0 and now we release 2.7.1).
The release/MAJOR.MINOR.x branch will be the branch from where all releases vMAJOR.MINOR.* will be done, and from where the gitbook documentation is built https://docs.zama.ai/concrete/v/MAJOR.MINOR.
Each push on the release branch will start all tests of Concrete. When you are happy with the state of the release branch, you need to update the API documentation:
If you miss it, the release worflow will stops on the release-checks steps on concrete_python_release.yml. Don't forget to push the updated API docs in the branch.
Then you just need to tag.
This new tag push will start the release workflow: the workflow builds all release artifacts then create a new draft release on GitHub which you can find at https://github.com/zama-ai/concrete/releases/tag/vMAJOR.MINOR.REVISION.
You should edit the changelog and the release documentation, then make it reviewed by the product marketing team.
When the new release documentation has been reviewed, you may save the release as a non draft release, then publish wheels on pypi using the https://github.com/zama-ai/concrete/actions/workflows/push_wheels_to_public_pypi.yml workflow, by setting the version number as MAJOR.MINOR.VERSION.
Follow the summary checklist:
At the end, check all the artifacts: