Daml SDK 1.4.0 has been released 12th August 2020. You can install it using:
daml install latest
This upgrade should require no action for almost all users. For a few special cases please see the Impact and Migration section below.
Interested in what's happening in the Daml community and broader ecosystem? If so we've got a juicy summary for you in our 1.4.0 announcement post.
daml codegen js is significantly faster when generating Javascript/TypeScript code
Migration from SDK 1.3 to 1.4 should require no action for almost all users.
The Daml Sandbox’s primary purpose is to serve as an in-memory development tool, but has had support for SQL backing for a long time. This made it a popular choice as a prototyping ledger and test tool, but lacking a separate distribution, required an entire SDK installation to run. To add clarity and ease deployment, the developer tool “Sandbox”, and the Ledger “Daml on SQL” are now being separated. As a first step, Daml on SQL is now available as a standalone JAR file on GitHub releases. Some minor changes to functionality and CLI are planned for upcoming releases to further differentiate developer tooling and actual Ledger. The standalone JAR will remain in Early Access until those changes have been made.
For now, this is a purely additive change, but at the same time Daml on SQL will become stable, persistence mode in Sandbox will be deprecated, and after a transition period, both support for persistence in Sandbox, and the already deprecated Sandbox-classic will be removed from the SDK. Users of Sandbox-classic or Sandbox with SQL backing are advised to start migrating over to the new Daml on SQL distribution.
Client applications have to be able to deal with the possibility that participant nodes become unavailable, for example due to network or hardware failure. For such cases, some Daml Ledgers offer the possibility to run hot (or cold) standbys of participant nodes. When a failover from a primary to a standby node occurs, the client application has to handle the possibility that due to latency or initialization, the standby is not yet fully caught up with the Ledger. Improvements to Ledger API and documentation makes this significantly easier.
INVALID_ARGUMENT to OUT_OF_RANGE.OUT_OF_RANGE error if the request offset is beyond the ledger end.
The behaviour of the transaction and command completion services have changed in cases where an offset beyond ledger end are given. This should only happen if a client application re-connects to a different node which is not fully caught up, so you are only likely to be affected if your application fails over.
If you were relying on the old behaviors (returning INVALID_ARGUMENT, or accepting the argument, respectively), you now need to handle the OUT_OF_RANGE error and implement retry logic.
Daml REPL, a developer tool to interactively evaluate Daml and interact with Daml Ledgers has been in Early Access since SDK 0.13.55. With this release, it becomes stable, meaning its developer facing APIs are final and won’t break outside of major SDK versions. In addition, it has gained a number of new useful features including the ability to run without being connected to a Daml Ledger, allowing interactive testing of pure functions, for example.
--ledger-host and --ledger-port parameters.:show imports.:help at the REPL prompt to see a list of possible REPL commands.:module [+-] Some.Module.let bindings to bind pure expressions
You now need to either explicitly import all modules of your DAR file using the --import flag, or use :module + … inside the REPL. For example, if you previously started the REPL with
daml repl .daml/dist/script-example-0.0.1.dar
you now need to either run
daml repl .daml/dist/script-example-0.0.1.dar --import script-example
or import modules individually with
:module + ScriptExample
The TypeScript/JavaScript codegen daml codegen js used to generate TypeScript files and then use yarn to compile these to JavaScript and declaration files. The codegen now generates JavaScript and declarations directly, significantly improving speed, and removing the dependency on yarn.
daml codegen js no longer requires yarn and is significantly faster.
No action is required to consume this improvement.
type X = Y) into the DAR,whenever possible, and will expose these synonyms via data-dependencies. This works for Daml-LF 1.8 (the current default) and upwards.daml new project-name --template=template-name instead of daml new project-name template-name. The positional arguments led to confusion so the named version is now preferred, but both continue to work. --participant-id switch.daml ledger commands now accept a --timeout option which can be used to change the timeout for API requests from the default of 30s.platform-version in your daml.yaml. This is useful if you are deploying to a ledger that is running components from a different SDK version. See https://docs.daml.com/tools/assistant.html#project-config-file-daml-yaml for details.daml new foobar --template=create-daml-app now properly respects the project name and creates a project called foobar in daml.yaml and package.json instead of hardcoding the name to create-daml-app.
--list. Docs: https://docs.daml.com/tools/ledger-api-test-tool/index.htmlGlobalKey => Option[ContractId] to GlobalKeyWithMaintainers => Option[ContractId] in Daml Enginecom.daml:participant-integration-api:VERSION instead of com.daml:ledger-api-server or com.daml:sandbox.StandaloneApiServer can now be run in a read-only mode
writeService of StandaloneApiServer changed to Option[WriteService]. Passing None will not start any of the admin services, the command service, and the command submission service.readService of StandaloneApiServer has been removed.ledgerId has been added to StandaloneApiServer. It is used to verify that StandaloneApiServer is run against an index storage for the same ledgerId. Initialization is aborted if this is not the case.LedgerConfigurationService now properly streams configuration changes.Engine constructor to Engine.StableConfig so it does not need to be overridden unless you specifically want to run in Engine.DevConfig modeLotsOfPartiesIT and TransactionScaleIT test suite have been deemed not providing relevant signal to Daml ledger implementers and have been retired. The tests will be nominally kept in but will be skipped while they are in a deprecation period. You are advised to remove explicit references to those tests before they are fully removed.--all-tests option is now ineffective and deprecated. You are advised to remove its usages from your build scripts. Non-isolated tests that could affect the global state of the ledger and interfere with other tests are now automatically scheduled by the test tool to run sequentially at the end of the run.--load-scale-factor option is now unused and deprecated. You are advised to remove its usages from your build scripts.
We are continuing to work on performance of the Daml integration components and improving production readiness of Daml Ledgers, but there are exciting features and improvements in the pipeline for the next few releases as well.