By SDK Release Process
Further readingRelease of Daml SDK 1.0 Release of Daml Connect 1.10.0 Release of Daml SDK 1.4.0 Release of Daml SDK 1.3.0 Release of Daml Connect 1.13.0
Release of Daml SDK 1.2.0
By SDK Release Process. Jun 5, 2020
Daml SDK 1.2.0 has been released 11th June 2020. You can install it using
daml install latest
This is a purely additive upgrade which comes with some minor new features and bug fixes. Upgrading should not require any intervention.
- Module prefixes can now be stored in
daml.yaml. This means that you can use multiple versions of libraries in the same project by specifying them in
daml.yamlinstead of with the
--packagecommand line flag.
- A new flag,
--max-lf-value-translation-cache-entries, allows you to set a number of events for which Daml-LF values will be cached. This can help reduce latency when serving transactions.
When upgrading a package using a Daml upgrade workflow, one has to import both the old and new version of the package as dependencies. If both the package and module names are the same, this used to require setting compiler flags. The new Module Prefixes feature gives an easier means of disambiguating the packages and modules.
The compiler picks up a new block module-prefixes specified in
daml.yaml. module-prefixes takes entries of the form package: Prefix, and modules from the package are then accessible using that prefix. For example, the below makes module
foo-1.0.0 available as
module-prefixes:<br> foo-1.0.0: Foo1<br> foo-2.0.0: Foo2
Refer to the documentation for detailed information.
Impact and Migration
This is a purely additive feature, so no migration is necessary. If your project uses the old
--package compiler flag to disambiguate packages, you can switch to this simpler method.
- The Sandbox’s
--max-lf-value-translation-cache-entriesoption allows you to set a number of events for which Daml-LF values are cached. This can reduce latency in serving transactions.
daml damlc inspect-darnow has a
--jsonflag to produce machine-readable output. See the documentation for more information.
- The Scala bindings have gained a method,
LedgerClient#close, which will shut down the channel and await termination. This is optional; the channel will still be shut down on JVM exit if this method is not called.
- Record dot syntax like
rec.field1.field2is now handled in expressions entered into the REPL.
daml replnow all support the
--max-inbound-message-sizecommand line flag, which configures the maximum size of transactions that can be handled.
createAndExerciseCmdcommand has been added to Daml Triggers.
Security and Bugfixes
- Dependencies have been upgraded to newer versions to avoid exposure to reported security vulnerabilities.
- Upgrade jackson version to 2.11.0 from 126.96.36.199
- Upgrade io.grpc:grpc-xxxxx and io.netty:netty-xxx version to latest
- Upgrade protobuf and protobuf-java to 3.11.0
- A Sandbox Classic migration issue when used with postgres has been fixed. See #6017
- A bug where large multi-command transactions would cause a stack overflow in Daml Script was fixed.
- The Standard Library’s
DA.Text.splitOnfunction will now correctly handle the case where the separator appears at the end but should not be matched, as in
splitOn "aa" "aaa" == ["", "a"]. See #5786 for more details.
- The Daml linter, dlint, has been improved by removing some Haskell-based rules not currently applicable to Daml and by changing some function references.
Ledger Integration Kit
- The Ledger API Server emits new metrics for the LF Value Cache. If the
--max-state-value-cache-sizeis greater than zero, the following additional metrics will be recorded under the
- Added new Ledger API Server metrics for
daml.index.db.*.translationto measure the time spent translating to and from the serialized Daml-LF values when fetched from the participant index.
- Added new Ledger API Server metrics for
daml.index.db.*.deserializationto measure the duration of the translation of the serialized Daml-LF values when fetched from the participant index.
- The Ledger API Test Tool has gained the TransactionSize performance benchmark test.
Our priorities for the imminent future remain unchanged.
- Daml Triggers currently need to be started one-by-one using the daml trigger command making them difficult to control dynamically at runtime. We are working on a solution to make them easier to use in practice.
- We will work to complete the Websockets streaming part of the JSON API.
- We will work to complete Daml REPL.
- Daml will get a generic Map type as part of Daml-LF 1.9.
- We will work to make the integration kit components used to build Daml Ledgers more performant.
- We will continue to work on our release process and to tighten the interfaces between different components of Daml so that we can give clearer compatibility and long term support guarantees.