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: Base, Celocli, Contractkit, Dappkit, Utils. 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:
CHANGELOG.md file, as mentioned above
Github releases page, as mentioned above
Discord: #developer-chat, #mainnet, and #sdk
For major releases:
Mailing list: cLabs’ Tech Sync
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.
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-dev and the final step should change the published version number from
For minor releases, the same process should be followed, except the
y value would increment, and the
z value would become 0.
For major releases, the same process should be followed, except the
x value would increment, and
z values 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
Base/Celocli/ContractKit/Utils - These all rely on each other quite bit, so triple check that these packages weren’t affected by a change in another.