Daml SDK 0.13.55 has been released on the 18th of March 2020. You can install it using
daml install latest
If you're planning to upgrade your Daml SDK to take advantage of our newest features please note that some action may be required on your part. If you're not planning to upgrade then no change is necessary.
Background
Being able to script the interaction with a Daml ledger is useful for testing, application initialization, and even one-off operations in production use. Daml scenarios cover a subset of those uses: Realtime testing and feedback in the IDE and ledger initialization in the Sandbox in static time mode. The main drawback of scenarios is that outside of the IDE, they only work with the Sandbox in static time mode and only during ledger initialisation. We have, therefore, built Daml Script, which generalizes the concepts behind Scenarios to work for any Daml Ledger, at any time. Going forward, we will deprecate ledger initialization based on Scenarios, and we recommend users to start using Daml Script now.
Specific Changes
Impact and Migration
Scenarios for Sandbox initialization will no longer be supported with the next SDK release in April 2020, but will continue to be supported for Daml model testing in the IDE and command line. If you are using a scenario to initialize the Sandbox today, we recommend migrating that to a Daml script. Daml Script has similar syntax to Scenarios, and the migration from scenarios to Daml script is documented.
Background
We are introducing an interactive read-eval-print-loop (REPL) for interacting with a Daml ledger. This feature is analogous to using an interactive shell session to examine and change the data in a relational database. It is based on Daml Script and allows accessing all functions from your Daml code. We encourage you to test this feature and provide feedback. It is still marked as experimental, so we can incorporate your feedback effectively and efficiently.
Specific Changes
Impact and Migration
Daml Repl is an entirely new feature, and no changes to existing projects are needed. Please refer to the docs for more information on this new functionality.
Background
One of Daml’s unique features is that the clear data ownership based on signatories allows for clean contract upgrades directly from within Daml. So far, this required SDK versions of the original and the new Daml contracts to be equal, a limitation that we obviously wanted to lift. This release lifts this restriction and adds support for contract migrations across SDK versions thanks to adding support for data-dependencies in daml.yaml.
dependencies and data-dependencies are source and binary dependencies respectively. dependencies should be used to include any libraries (e.g. the Daml Standard Library) that are always deployed together with the project, whereas data-dependencies should be used for any dependencies that are independently deployable, for example the Daml Finance Library, or applications already running on the target ledger.
Specific Changes
Impact and Migration
To make use of this feature, Daml projects have to be compiled to Daml-LF 1.8. The current default is still 1.7, and so this has to be done by passing in the flag --target=1.8. Detailed information on the upgrading and dependency functionality can be found in the docs.
Data constructors that don’t match record type names have to be renamed. For example, if you had a record type data Foo = Bar with .., you need to change it to data Foo = Foo with ..
Background
The project file daml.yaml should tell the Daml Assistant CLI everything it needs to know to set up a test environment using daml start. However, until this release, there were certain Sandbox, Navigator, and HTTP JSON API settings that needed to be set through additional command line flags. These can now be set using sandbox-options, navigator-options and json-api-options sections in daml.yaml.
Specific changes
Impact and Migration
Command line arguments like daml start --sandbox-option="--wall-clock-time" will keep working as before, but you can now simplify your CLI usage moving them into daml.yaml.
Background
Privacy is one of Daml’s primary concerns, with visibility of data usually constrained to signatories and observers of contracts. However, there are two well-documented and controlled mechanisms through which non-observers can learn about contracts: Divulgence and Witnessing.
Whether events or contracts that are known due to those mechanisms are shown in APIs or tools used to be inconsistent and led to oddities such as the Navigator showing assets that had been transferred. This change addresses these inconsistencies and ensures divulged and witnessed contracts are only included in APIs returning transaction trees.
Specific Changes
Impact and Migration
Applications are unlikely to be accidentally relying on the current behaviour so there is probably little to no impact on existing Daml applications.
In general, if you want to share data on a Daml ledger, we recommend using the observer mechanism or sharing it in dedicated sharing contracts as highlighted in the Broadcast Example.
Background
For certain applications, it is crucially important that commands will not be processed twice, even if application or ledger components crash or network links fail. The new command deduplication mechanism gives a way to achieve that.
The previous mechanism based on Maximum Record Time (MRT) and Checkpoints on the CompletionStream was difficult to use in practice and didn’t generalise to ledgers without a linearly ordered record time. The new mechanism is designed to replace the old one over the course of the next Daml SDK releases.
Specific Change
Impact and Migration
The maximum record time based mechanism for command deduplication is now deprecated and will be removed with the next SDK release. We recommend switching from the MRT-based mechanism to deduplication_time based one. Detailed documentation here.