Skip to main content

​
Versioning

All Canton and Daml SDK components follow Semantic Versioning. In short, this means that there is a well defined “public API”, changes or breakages to which are indicated by the version number. Stable releases have versions MAJOR.MINOR.PATCH. Segments of the version are incremented according to the following rules:
  1. MAJOR version when there are incompatible API changes,
  2. MINOR version when functionality is added in a backwards compatible manner, and
  3. PATCH version when there are only backwards compatible bug fixes.

​
Cadence

Regular, weekly patch releases are made with additional releases produced as needed. These releases contain Canton and Daml SDK components; the current release line is Canton 3.5 (3.5.x). See the Version Compatibility Dashboard for the versions currently deployed on each network. The decision to perform a Minor version release is based on the content or scope of the payload of that release. The intent is to release a Minor version once a quarter but this may change based on the customer demand for new, key features. No more than one major version is released every six months, barring exceptional circumstances.

​
Support duration

Major versions are supported for a minimum of one year after a subsequent Major version is released. Within a major version, security and bug fixes are applied to the latest Minor version as well as the second to last Minor version release, the latter being limited to 6 months after its release or 3 months after the release of the latest Minor version, whichever is longer.

​
Release notes

Release notes for each release are published in Release Notes, including Canton and Splice release notes.

​
Process

Weekly and Minor releases follow a common process. The process is documented in the Daml repository. Only the schedule for Minor releases is covered below. Selecting a release candidate This is done by the core engineering teams. The Minor releases are scope-based. Furthermore, development is fully HEAD-based so both the repository and every snapshot are intended to be in a fully releasable state at every point. The release process therefore starts with “selecting a release candidate”. Typically the snapshot from the preceding Wednesday is selected as the release candidate. Release notes and candidate review After selecting the release candidate, release notes are written and reviewed with a particular view towards unintended changes and violations of Semantic Versioning. Release candidate refinement If issues surface in the initial review, the issues are resolved and a different snapshot is selected as the release candidate. Release candidate announcement Barring delays due to issues during initial review, the release candidate is announced publicly with accompanying release notes. Communications, testing, and feedback In the days following the announcement, the release is presented and discussed with both commercial and community users. It is also validated by deployment through the Canton Network’s progression of environments (DevNet and TestNet) before reaching MainNet. Release candidate refinement II Depending on feedback and test results, new release candidates may be issued iteratively. Depending on the severity of changes from release candidate to release candidate, the testing period is extended more or less. Release Assuming the release is not postponed due to extended test periods or newly discovered issues in the release candidate, the release is declared stable and given a regular version number.