X.Y format. X represents the major version, and Y represents the minor version.
Each minor release adopts a new set of Daml models. These are compatible upgrades of the models released in the previous minor release.
The major version is incremented when there are breaking changes that require an extensive contract migration.
We follow a staggered roll-out approach, where a new release is first rolled out to DevNet, then TestNet, and finally to MainNet, at 1 week intervals.
Backwards compatibility
At any given time, we strive to support the two minor versions before the current release. For instance, together with the rollout of0.12, we would be dropping support for version 0.9. What that means is that we expect transactions submitted using 0.9 versions of the Daml packages to fail. We however expect transactions submitted using 0.10 or 0.11 package versions to continue to work.
Our current release schedule of at most one release per month should provide sufficient time to upgrade to the new package versions.
Deprecation of the old version, as well as the target upgrade path for integrations, is communicated as part of the release notes.
Adopting a new release
In order to adopt a new release, it is sufficient for the newly introduced Daml packages to be uploaded and vetted by the operator of your validator node.If you have built off-ledger or on-ledger integrations with the Registry App, you should only adopt a new release once you have verified that your integration can consume it on one of the lower environments. We provide an Integration Guide as part of the Release Notes for each release.