2021-12-01 13:26:59 +03:00
|
|
|
1d0ff3cc71583f738489e7732fa758a39f9cbfbd 2.0.0-snapshot.20211201.8538.0.1d0ff3cc
|
2021-12-06 15:39:04 +03:00
|
|
|
2c945fcb3a2ca0972fbf8f222420b286f20b29e7 1.18.0-snapshot.20211206.8423.0.2c945fcb
|
2021-12-02 13:22:48 +03:00
|
|
|
b33b94b85c23235a9d62fb7a9967f1f91247ed76 1.17.2-snapshot.20211124.7857.0.b33b94b8
|
2021-10-11 10:04:21 +03:00
|
|
|
e05be36512ade4d9cb6921614c23dadbde1747a3 1.17.1
|
2021-09-29 13:44:34 +03:00
|
|
|
49a75801fbafa1ffab3247ecfbb06a82925e8a0b 1.17.0
|
2021-08-11 13:13:06 +03:00
|
|
|
48050ad7836b9825c9dc7bd96fbc980b8eb9b6e5 1.16.0
|
2021-07-14 18:23:13 +03:00
|
|
|
aca22721f709d879a49fa958a1eb0b532fcbde54 1.15.0
|
2021-07-09 13:09:31 +03:00
|
|
|
aa2978400dd88a6011db18a62fb71c23ebd9d20b 1.14.2
|
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
|
Release 1.11.3-snapshot.20211123.6448.0.c679b4ab (#11981)
Changelog
---------
```
- [JSON-API] added metrics to separately track:
- time taken to update query-store ACS (from ledger)
- lookup times for the query store
[HTTP/JSON API]
- metrics reporting can now be chosen via the command line option --metrics-reporter (currently hidden), valid options are console, csv://, graphite:// and prometheus://
- metrics reporting interval can also now be chosen via a command line option --metrics-reporting-interval (currently hidden)
- [Ledger HTTP Json Service] Logging output can now be in JSON either via providing the cli option `--log-encoder json` or via setting the env var `LOG_FORMAT_JSON=true`
[HTTP-JSON]
- fixed that json log output could not be enabled via cli options except via usage of env vars
- [Ledger HTTP Json service] Logging can now be configured via the `--log-level` cli argument. Valid values are `error`, `warn`, `info` (default), `debug`, `trace`
- [Ledger HTTP Json Service] Logging now also tells service name if log level was changed.
http-json:
- add contextual id as logging context to distinguish different application runs in logs
- add request id as logging context to distinguish different http requests within an application run
- add for non-static endpoints trace logs which show how long processing it took in ns
- [JSON API] Fix an error where transactions that delete a large
number of contracts resulted in stackoverflows with the PostgreSQL
backend and database errors with Oracle.
- [JSON API] While updating the contract table for a query, if the DB appears to be slow,
JSON API will slow down its own inserts and deletes at some point rather than construct
ever-larger INSERT and DELETE batch commands.
See `issue #11589 <https://github.com/digital-asset/daml/pull/11589>`__.
Backport of Hikari connection pool for 1.11.x plus addition of configurable connection pool properties to jdbcConfig string, the properties are listed below
poolSize -- specifies the max pool size for the database connection pool
minIdle -- specifies the min idle connections for database connection pool
connectionTimeout -- long value, specifies the connection timeout for database connection pool
idleTimeout -- long value, specifies the idle timeout for the database connection pool
[Ledger API] Retry the interpretation of a command in case of a race
with other transactions. This fix drastically reduces the likelihood of the error
"Could not find a suitable ledger time after 0 retries".
For every update in the index db log the full context at the INFO level.
[Integration Kit] The state of the participant indexer can now be checked via the GRPC health endpoint
```
Commits
-------
```
c679b4ab23 [1.11.x] Metrics for investigating json api performance (#11769)
437c3d4639 Bump Windows postgres (#11806)
382168b7f0 Add metrics to the http json service (#9923) (#11768)
b7fc305427 [Backport] Add cli option & system property to enable json only logging for the json api (#11717)
17cacb05f1 [Backport] Add logging command line option to ledger http service (#9581) (#11699)
56531e8610 Backport: Support deletion of a large number of contracts (#11646)
6bf19fce82 Backport: limit contract insertion/deletion batching on backpressure (#11647)
eed4ad32b7 Backport signing tool changes (#11651)
ee7547ed88 [JSON-API] Backport of connection pool for 1.11.x , configurable db options needs forward porting (#11615)
632ba5a7b3 Backport: Avoid collision in execution log postfix (#11644)
cf4f1a1d8f Backport: add tar to dev-env (#10173) (#11636)
b78fa8c4a3 Backport: Restart the submission interpretation in case of a race [DPP-737] (#11578)
5c3220d2db Fix build of release/1.11.x branch (#11582)
cce7c79ec5 Log context of all updates written to the database (#10057)
a9d0473473 Adds Indexer state to GRPC health checks [DPP-434] (#9951) (#9961)
```
changelog_begin
changelog_end
2021-12-06 19:53:12 +03:00
|
|
|
c679b4ab238f183fc54d7118e5a633097cb4813b 1.11.3-snapshot.20211123.6448.0.c679b4ab
|
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
|