Celo Oracles Release Process
Details of the release process for updating the Celo Oracles Client for the Mento Stability Protocol.
Releases of are made as needed. Releases are numbered according to semantic versioning, as described at semver.org.
Development builds should be identified with a
-dev suffix, and only one commit should exist with a released version
x.y.z for any
(x, y, z). Release candidates should be identified with a
-rCX suffix, where X is the version of the release candidate.
Code for the client is stored in the Celo Oracles GitHub repository. Development is done on the
main branch, which corresponds to the next major or minor version.
Each release should be created on Github and tagged with the version number, e.g.
X.Y.Z. Each release should include a summary of the release contents, including links to pull requests and issues with detailed description of any notable changes. Tags should be annotated tags.
Tags should be signed and can be verified with the following command.
git verify-tag vX.Y.Z
On Github, each release tag should have attached signatures that can be used to verify the Docker images.
Docker images are stored in the repository
us-west1-docker.pkg.dev/celo-testnet-production/celo-oracle repository, stored in Google Cloud Platform Artifact Registry. Commits there are tagged with
celo-oracle-<commithash>. Just as a Git tag immutably points to a commit hash, the Docker tag should immutably point to an image hash.
As well as automated CI tests, all releases are expected to go through manual testing as needed to verify security properties, accuracy of documentation, and compatibility with current node operators production set up.
Cherry picked branch changes shall be added to a
releases protected branch. When merging code to this branch, the version number should be updated accordingly.
Security fixes or hotfixes may not have a public commit attached to them in case the vulnerability needs to be patched before disclosing to the general public to prevent an attacker to exploit a vulnerability before operators patch their services. Emergency patches will be distributed using the same method described in Git tags
Vulnerabilities in Celo Oracles should be disclosed according to the security policy.