We are proud to announce the release of Open Zaak 1.5.0! We have introduced
a number of new features, such as rootless container images, generic OpenID
Connect integration, performance improvements and a number of bugfixes.
Additionally, we have also updated the various deployment toolsets.
BEFORE upgrading, please make sure to read the release notes (
and detailed upgrade instructions, as 1.5.0 requires some special
attention. You can read these here:
Additionally, Open Notificaties 1.2.1 has been released for a while without
any spotlight shining on it. The 1.2.x line also has container image best
practices applied. The changelog is available on
Please note that Open Notificaties no longer supports RabbitMQ as celery
result backend. This should not be a problem if you deploy using our
Ansible collection or Helm charts, but if you're running your own tooling,
you have to switch to Redis for this. You can review the Ansible roles or
Helm charts as a reference, they have been updated.
We recommend everyone to upgrade to these new versions, if only for the
better practices applied in the container images.
As a final note and announced earlier in this mailing list, we also want to
point out that you can sign up to the "Release Early Notice List" on
The Open Zaak technical steering team provides these notifications for some
releases because system administrators need time to schedule an update,
which can be especially important if a security vulnerability was resolved
in the update.
After the summer vacation, the technical steering meetings didn't continue.
In my opinion, this is fine and we only need to meet if necessary. But, I
think it's necessary to discuss a topic that we're struggling with at the
*Topic: Adding non-standard API features into Open Zaak*
In short, Open Zaak currently has version 1.0 of all ZGW API's implemented.
The ZGW API specifications however are evolving. Some of these API changes
are needed "now" and the question arrives if we should just add this
filter, this extra field, etc. without moving the entire API to the next
version (because that takes more time/money). Some features might even be
planned for a future version of the specification that is not released yet
(but we need now!)
The question: Should we be allowed to add some of these non-standard
features into Open Zaak (properly documented as a difference, and only if
it's in line with the future of the specifications)?
I propose to discuss this (and perhaps other topics) in the next meeting,
which I'll schedule on December 8, 14.00. If I don't hear anything before
November 17, I'll assume this date and time are okay.
Een initiatief van Maykin Media
Keizersgracht 117, 1015 CJ Amsterdam
tel.: +31 (0)20 753 05 23