release 1.15.0-snapshot.20210630.7261.0.84e1f3a7 (#10146)
This PR has been created by a script, which is not very smart
and does not have all the context. Please do double-check that
the version prefix is correct before merging.
@sofiafaro-da is in charge of this release.
Commit log:
```
84e1f3a7f173f3cec185dec6b478701065109796 participant-integration-api: Move transaction requests to structured logging. [KVL-996] (#10141)
b79d02e28e2086f8d868f1771685ff81a5c74732 `ledger-api-bench-tool` - exposed metrics for Prometheus [DPP-471] (#10103)
b61e519a3a8c89800b80b9bd4b8e5160205e961a Release ledger API test tool per LF version (#10142)
2dfe026cc239f7f6252882ed738f71a650af9f32 add ES cluster (#10144)
ef9a04caf5707011b2d2fc639548251028075371 Divulgence crash tests [DPP-433] (#9942)
bb4641756f5e9dc5dc689a166ce880b6210e86db Daml assistant capitalization (#10140)
a6ee10be9a41f9757c7fc3ee5ad1c1ba0da75017 Move visibility checks into speedy. (#10136)
c764fbe573a0a131ebb9e27b8ca0a93569a2d45f contextualized-logging: Introduce different logging types for more structure. [KVL-996] (#10134)
678cab032750560b1ad6725030a8ee09174e24c6 10050 append only schema on oracle (#10051)
f5e506247044cf607e7a7989c0ce7d250f269ca2 ensure that signatories and observers are disjoint in ledger-api CreatedEvents (#10123)
ffc88d52b438dce5703b1b20d7d82f6f3d63337b print version of the ledger api test tool as part of the report (#10119)
621cfa4a91acaca6896d1235741465f25c623c8d Resolve contract keys conflicts in disclosed contracts (#9948) (#10034)
f1ffd52e08c1741d2a962db9c71074f5c130d716 Java bindings: add DamlRecord, deprecate Record (#10132)
3df256630579a91f2f9899de9f143c7ef992b72b Scenario: move Scenario Error Throwable to scenario package (#10075)
7521ec998807f9093c7fe4653d8ee292441a7968 [JSON-API] Include contract id in the logging ctx when logging exercise commands (#10131)
e0e333377c2bfeb3723c28ae140d5a223e60727d update NOTICES file (#10129)
398300b76f8e5e12b261d204e4cbe30e70afbe40 LF: Move Speedy Interpretation Error to transaction package (#10091)
d4150ac078d41400970fb2327eef70bd0e741513 Refactor error reporting in Daml Repl (#10118)
0108fedd4e652e40f5dd83b2e58d577574f84872 update NOTICES file (#10112)
6af36fe1e3980e2652d21335aa717db8d5e1e636 Fix Tx.Metadata for normalized transactions (#10108)
774569364826b9670847bbff3c76208a1c6c1be2 Remove duplicate index (#10084)
1b617ae22d625bae51d95360cd3ed3d6a879b7f9 DPP-428 Add missing indices for index initialization (#10083)
af9382ce92a84425a0a6d28ec2fcd7da21bd22dd contextualized-logging: Reduce the API surface and avoid name collisions. (#10102)
01d67704502ef581891b5b6fde0163c341abb762 json-api perf tests: combine large-ACS frequencies combinatorially instead of in lockstep (#10101)
a44afcff420f217f8a6a6c2834a387efc2bdb7ff Upgrade nixpkgs (#9908)
9498d1509b6fcefdb8832f553f206c992f3e0a03 [DOCS] Let jwt.io link to an already filled in working payload (#10026)
4affb053e99a44b745038dbbf2fff305495fe44c Force newer version of glob-parent in Navigator (#10105)
f745f10394e1462192f98b62dfcb72e94ff5ef94 LF: Realease LF 1.14 (#10077)
05056ddd8c09550566f554124d059aff1f29fc7b Cut a flaky expectation some more slack (#10106)
46a66e2f2a879c11e36014cf3db4c4029ebe1e33 Upgrade jest to the latest version (#10107)
84e329885faf8ac2a5b440187562462751c2abde update compat versions for 1.11.2 (#10104)
a6b536f3c45f2dbfdd6c02fc6d97ad53342569b3 Compiler: Make LF 1.13 the default output (#9907)
29ddc88dcbd0dfb9abdd1db304433cc366424b1a remove redundant spaces in the log format (#10093)
01e329f2de7bf846f4817ef84a81e84a6850d7d4 DPP-432 Add exception tests to the JdbcLedgerDao suite (#10040)
3d79cbf2b13a7c2abc734a7e1de17a6cda1798a4 Bump compat versions (#10096)
5bf7d8f5706b9672df7a8c3ee23a55554df312e1 Fix speedy perf reporting (#10100)
0970821ce7525bf5b9d79ca96ca9a79cb76a2bd7 Bump cpu alloc for build-and-lint (#10099)
cbca7796578577e7b8bdc09bce00b08a102cf225 [In-memory fan-out] Ensure getTransactionLogUpdates with max fetch size (#10064)
c756153951853a3bf4ddd20bd30af8a79fa87615 Release SDK 1.11.2 (#10094)
3a4235400d2160bb35338a21f4465d5482567d76 rotate release duty after 1.15.0-snapshot.20210622.7213.0.d867d904 (#10086)
ecc2d115368f4b1c230007d221db9d84980b53f1 recommend some daml compiler warnings to enable (#10082)
b2bb45e4d95aa8f5a950915a56f8ec386f5aee28 Bump daml repl timeout (#10089)
db60d15b5e29f85c89ee5db24ef0ec778946bd5e Log ledger api validation failures at info level (#10080)
f0dc025ac9c36ed4950b9b27ffc87b6756ebd0cc Release 1.15 snapshot (#10090)
```
Changelog:
```
- [Ledger API Server] The amount of data logged in the API transaction
service has been reduced at INFO level. Please enable TRACE logging to
log the request data structures.
- [Integration Kit] - ledger-api-bench-tool - exposed metrics via Dropwizard metrics (e.g. for Prometheus)
- The log output of Daml components has changed so that the structured
part is closer to JSON. This allows us to distinguish and parse
numbers and lists. If you are parsing this log output, you may need to
change your parser.
The log output has changed from:
.. code-block::
context: {a=b, x=1, foo=bar, parties=[alice, bob]}
to:
.. code-block::
context: {a: "b", x: 1, foo: "bar", parties: ["alice", "bob"]}
In case a contract key is already present in a past contract in the contract table nullify it. This gets rid of contract keys of previously disclosed contracts. We never discover that disclosed contracts get archived, so we get conflicts on such past keys
[Java bindings] In order to avoid clashing with `java.lang.Record` (introduced
in Java 14), `com.daml.ledger.javaapi.data.Record` has been renamed to
`com.daml.ledger.javaapi.data.DamlRecord`. The old name has been used to
denote a sub-type of the newly renamed one, so it can still be used, but it has
been marked as deprecated.
[Java codegen] The Java codegen now uses the `DamlRecord` type wherever `Record`
was used before.
- [JSON-API] The contract id is now also included in the logging ctx when logging exercise commands
- [LF] Add support for Excepction
- [Compiler] Default ouput LF version is now 1.13
Log ledger api validation failures at info level
```
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Azure Pipelines DAML Build <support@digitalasset.com>
2021-06-30 11:27:09 +03:00
|
|
|
84e1f3a7f173f3cec185dec6b478701065109796 1.15.0-snapshot.20210630.7261.0.84e1f3a7
|
2021-06-17 11:11:09 +03:00
|
|
|
d1b54ff0a0213d0f88a30078dacae06744529773 1.14.0
|
2021-05-17 12:42:07 +03:00
|
|
|
5f5323806b9ee704dc7f5bed5c458ee9d0c431f7 1.13.1
|
2021-05-12 11:32:09 +03:00
|
|
|
9ae787d005a5ea5c3c65aef9f56a56082ea4c167 1.13.0
|
2021-04-14 11:40:41 +03:00
|
|
|
631db446f0e5f24845b9837ffcf8ea6061f91f4f 1.12.0
|
2021-06-23 19:26:47 +03:00
|
|
|
a08f6ea24245461e912f2be5676009dcbea05634 1.11.2
|
2021-03-17 12:52:56 +03:00
|
|
|
7cd6380e156810ec7a19abbb3b967f45acab00b9 1.11.1
|
2021-03-10 12:14:25 +03:00
|
|
|
d3d5042ac04f4c0f755df7e87bc191716fdecc4c 1.11.0
|
2021-03-03 21:31:53 +03:00
|
|
|
80d080ef9f1c63de6f94d22592f89d623bfb1fa6 1.10.2
|
2021-02-17 15:17:12 +03:00
|
|
|
19bf4031f551334ff70a77bbf469b8af8e061bf2 1.10.0
|
2021-01-20 18:42:38 +03:00
|
|
|
5b3663a500e6840109e0e3e21cd6dea3c546573d 1.9.0
|
2021-03-03 20:44:59 +03:00
|
|
|
d443707c1893b58206f2f2ba62a18cd25e1ff53c 1.8.0-snapshot.20210303.5843.0.d443707c
|
2021-01-18 17:08:19 +03:00
|
|
|
59f5d40754bebf76f0530d94eb4c723cba21a21b 1.8.1
|
2020-12-16 11:46:55 +03:00
|
|
|
38455e8ca91ca3c351a6d15bd9ec25070386fc6c 1.8.0
|
2020-11-11 12:26:41 +03:00
|
|
|
e75d42ddc3150c0e054c35cc8c5afcf523ed5702 1.7.0
|
2020-12-21 17:17:34 +03:00
|
|
|
547abc97d96ad9ab4ed6e5fb6acf4c05ae85b639 1.6.1
|
2020-10-15 11:47:32 +03:00
|
|
|
d21cb496b7373dcf5c7afcc373b7898cbe54019e 1.6.0
|
2020-09-16 11:51:45 +03:00
|
|
|
eb68e680f649bc7c2b6b2c3b8a4c7a664f52ecec 1.5.0
|
2020-08-12 14:12:17 +03:00
|
|
|
224ab3621c8c3745aa5af78f655b4676794d7a5f 1.4.0
|
2020-07-16 13:07:34 +03:00
|
|
|
8e10c7a7338d72b907ae72f77c03b06cbe8426af 1.3.0
|
2020-07-06 16:06:48 +03:00
|
|
|
11b5c36282407284122326c4d80cb7a6015ed825 1.3.0-snapshot.20200610.4413.0.11b5c362
|
2020-06-10 13:36:31 +03:00
|
|
|
1c18058f019229cd0af64669af0de31d0cec916d 1.2.0
|
trigger all releases from master (#6016)
trigger all releases from master
The 1.1.0 release went wrong and we had to trash it and release 1.1.1
instead. This is an attempt at identifying and correcting the root
cause behind that incident.
To understand the situation, we need to know how releases worked before
1.0. We had a one-line file called `LATEST` that specifies the git SHA and
version tag for the latest release. A change to that file triggered a
release with the specified release tag, built from the source tree of
the specified commit. The `LATEST` file looked something like:
```
f050da78c9c8727b889bdac286156f19e2f938c4 1.0.0-snapshot.20200411.3905.0.f050da78
```
To mark a release as stable, we would change it to look like this:
```
f050da78c9c8727b889bdac286156f19e2f938c4 1.0.0
```
i.e. simply drop the `-snapshot...` suffix. Even though the commit (and
thus the entire source tree we build from) is the same, we would need to
rebuild almost all of our release artifacts, as they embed the version
tag in various places and ways. That worked well as long as we could
assume we were doing trunk-based development, i.e. all releases would
always come from the same (`master`) branch.
When we released 1.0, and started work on 1.1, we had a few bug reports
for 1.0 that we decided should be resolved in a point release. We
decided that the best way to handle that would be to have a branch
starting on the release commit for 1.0, and then backport patches from
`master` to that branch. We adapted our build process to also watch the
`release/1.0.x` branch and, in particular, trigger a new release build if
the `LATEST` file in that branch changed. That worked well.
The plan going forward was to keep doing regular snapshot releases from
the `master` branch, and create support, point releases ("patch" releases
in semver) from dedicated branches.
On April 30, we made a snapshot release as an RC for 1.1.0, by changing
the `LATEST` file in the `master` branch. That release was built on commit
681c862d. On May 6, we decided to take a new snapshot as the RC for
1.1.0; we changed `LATEST` in `master` to designate 7e448d81 as the new
latest release.
On May 11, we noticed an issue that broke our builds. Without going into
details, an external artifact we depend on had changed in incompatible
ways. After fixing that on `master`, we reasoned that this would also
break the build of the final 1.1.0 release if we just tried to build
7e448d81 again. But as the target release date was May 13, we did not
want to take a new snapshot after that fix, as that would have included
one more week of work in the release, and given us no time to test it.
So we did what we did for the 1.0 branch, as it had worked well: we
created a branch that forked from `master` at commit 7e448d81 and called
it `release/1.1.x`, then cherry-picked the one fix to our build process to
work around the broken download. When the time came to make the final
1.1.0 build on May 13, we naturally picked the `LATEST` file from the
`release/1.1.x` branch and dropped the `-snapshot...` suffix. Importantly,
we did not need to update the target commit to include the "broken
download" fix as, in the meantime, the internet had fixed itself, and we
thus reasoned we should go for the exact code of the RC rather than
include an unnecessary, albeit seemingly harmless, change.
Everything went well with the release process. Tests went well too. Then
we got a report that an application that worked against the latest RC
broke with the final 1.1.0. The issue was that we had built the wrong
commit: by branching off at the point of the _target_ commit for the
latest snapshot, we did not have the change to the `LATEST` file that
designated that commit as the target. So the `LATEST` file in
`release/1.1.x` was still pointing to 681c862d.
I believe the root cause for this issue is the fact that we have
scattered our release process over multiple branches, meaning there is
no linear history of what was released and we are relying on people
being able to mentally manage multiple timelines. Therefore, I propose
to fix our release process so this should not happen again by
linearizing the release process, i.e. getting back to a situation where
all releases are made from a single branch, `master`.
Because we do want to be able to release _for_ multiple release branches
(to provide backports and bugfixes), we still need some way to
accommodate that. Having a single `LATEST` file in the same format as
before would not really work well: keeping track of interleaved release
streams on a single file would not really be easier than keeping track
of multiple branches.
My proposed solution is to instead have a multiline LATEST file, so that
all the release branch "tips" can be observed at the same time, and, as
long as we take care to only advance one release branch at a time, we
can easily keep track of each of them. This is what this PR does.
This required a few changes to our release process. Most notably:
- Obviously, as this is the main point of this PR, the build process has
once again been restricted to only trigger new releases from the
`master` branch.
- As our CI machinery cannot easily be made to produce multiple releases
from a single build, the `check_for_release` step will only recognize
a commit as a release trigger if it changes a single line in the
`LATEST` file. This restriction comes in addition to the existing one
that a release commit is only allowed to change either just the
`LATEST` file or both the `LATEST` and
`docs/source/support/release-notes.rst` files.
- The docs publication process has been changed to update _all_
published versions to display the _latest_ release notes page. This
means that the release notes page will always show you all published
versions, regardless of which version of the documentation you're
looking at. This also means that interleaving release notes correctly on
that page is a manual exercise.
- As per the intention of the new process, the `LATEST` file has been
updated to contained all existing post-1.0 stable releases. It should
also include all existing snapshot releases should we have more than one
at a time (say, should we discover an issue with 1.1.1 that required us
to work on a 1.1.2).
- The `release.sh` script has been dramatically simplified as I felt it
was trying to do too much and porting its existing functionality to a
multi-line `LATEST` file would be too hard.
CHANGELOG_BEGIN
CHANGELOG_END
2020-05-19 20:18:10 +03:00
|
|
|
7e448d810c1134c39afa2c555e85964b68976446 1.1.1
|
|
|
|
|
160936905d393a6f8fb35ea02ad6b3c401820dad 1.0.1
|
|
|
|
|
f050da78c9c8727b889bdac286156f19e2f938c4 1.0.0
|
