Release Process for CeloCLI and ContractKit
Details of the release process for updating CeloCLI and ContractKit on the Celo platform.
Use the standard MAJOR.MINOR.PATCH semantic versioning scheme described at semver.org.
New releases can be expected as follows:
- Major releases: approximately yearly
- Minor releases: approximately 8 times a year
- Patch releases: as needed
Development builds will be identified as such:
x.y.z-dev, and will be published as
x.y.z when stable.
You can find the npm packages in the following places:
To identify the commits included in a specific release and see which new features were added or bugs fixed, please refer to the release notes in the monorepo. Also to keep track of continual updates to the stable and dev versions of the packages, each package has a
CHANGELOG.md file: Celocli and Contractkit.
All releases should be tagged with the version number, e.g.
contractkit-vX.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.
The community will be notified of package updates through the following channels:
For all releases:
- Each package’s
CHANGELOG.mdfile, as mentioned above
- Github releases page, as mentioned above
- Discord: #developer-chat, #mainnet, and #sdk
For major releases:
- Twitter: @CeloDevs
- Mailing list: cLabs’ Tech Sync
- Celo Forum
The packages are published by following the instructions here.
All builds of these packages are automatically tested for performance and backwards compatibility in CI. Any regressions in these tests should be considered a blocker for a release. Minor and major releases are expected to go through additional rounds of manual testing as needed to verify behavior under stress conditions.
Work in progress
- For a patch release: The first step of this process should be a commit that changes the version number encoded in the source from
x.y.z+1-devand the final step should change the published version number from
- For minor releases, the same process should be followed, except the
yvalue would increment, and the
zvalue would become 0.
- For major releases, the same process should be followed, except the
xvalue would increment, and
zvalues would become 0.
Only one commit should ever have a non-dev tag at any given version number. When that commit is created, a tag should be added along with release notes. Once the tag is published it should not be reused for any further release or changes.
Bugs which affect the security, stability, or core functionality of the network may need to be released outside the standard release cycle. In this case, an emergency patch release should be created on top of all supported minor releases which contains the minimal change and corresponding test for the fix. An emergency patch retro will also be published, and will include information such as why the patch was necessary and what code changes it includes.
Vulnerabilities in any of these releases should be disclosed according to the security policy.
- @celo/mobile - Dappkit relies on this
- All the packages under the "SDK" folder -- These all rely on each other quite bit, so triple check that these packages weren’t affected by a change in another.
- All the packages under the "SDK" folder