Releases
3.3.0

3.3.0

Release notes for version 3.3.0 of the Rhize application.

Release date: 19 Feb 2026

Changes by service

The following sections document the changes this release brings to each service.

Admin

  • Change to align with v3.3.0 schema changes

BPMN engine

Add

  • Add libre-schema library v3.3.0 for type safety

Change

  • Change rhize-go library to v3.3.0
  • Change high-availability test case image versions to align with compatibility versions

Schema

Add

  • Add regexpcompare and hash filter to JobResponse.id
  • Add regexpcompare and hash filter to JobResponseData.description
  • Add regexpcompare and hash filter to JobResponseData.id
  • Add regexpcompare and hash filter to JobResponseData.label
  • Add regexpcompare and hash filter to JobResponseData.value
  • Add regexpcompare and hash filter to OperationsEvent.id
  • Add regexpcompare and hash filter to OperationsEventRecord.description
  • Add regexpcompare and hash filter to OperationsEventRecord.id
  • Add regexpcompare and hash filter to OperationsEventRecordEntry.id
  • Add regexpcompare and hash filter to OperationsEventRecordEntry.recordId
  • Add Segment resource Specifications including Segment resource Specification properties

Change

  • Change BAAS Docker image tag to v3.3.0-rc2 in CI and docs to include regexpcompare
  • Change cardinality of defines and definedBy on WorkMasters to align with their descriptions
  • Change cardinality to of the number of ProcessSegments to 0..n that a WorkMaster can fulfil
  • Change cardinality to of the number of OperationsSegments to 0..n that a WorkMaster can fulfil
  • Change cardinality to of the number of OperationsDefinition to 0..n that a WorkMaster can fulfil
  • Change description of EquipmentUse attribute to align with the standard
  • Change default baas container to use v3.3.0-rc2 to include regexpcompare filter type
  • Change physicalSample to a required field on a TestSpecification
  • Change ProcessSegmentVersion to link to Segment resource specification instead of resource specification
  • Change Test Specification has inverse field for EquipmentSpecification, PersonnelSpecification, PhysicalAssetSpecification and MaterialSpecifications to align with the description
  • Change the cardinality of testResults to 0..n on a PersonnelSpecification
  • Change the relationship names for a OperationsDefinition to itself from children, parent to defines, definedBy respectively
  • Change rover version to pin to v0.36.2 from latest for compatible pipeline builds

Fix

  • Fix description of a PhysicalAssetSpecification.id

Remove

  • Remove processSegmentVersion from <resource>Specifications as it now links to a Segment<resource>Specification
  • Remove regexp, fulltext and exact filter from JobResponse.id
  • Remove regexp, fulltext and exact filter from JobResponseData.description
  • Remove regexp, fulltext and exact filter from JobResponseData.id
  • Remove regexp, fulltext and exact filter from JobResponseData.label
  • Remove regexp, fulltext and exact filter from JobResponseData.value
  • Remove regexp, fulltext and exact filter from OperationsEvent.id
  • Remove regexp, fulltext and exact filter from OperationsEventRecord.description
  • Remove regexp, fulltext and exact filter from OperationsEventRecord.id
  • Remove regexp, fulltext and exact filter from OperationsEventRecordEntry.id
  • Remove regexp, fulltext and exact filter from OperationsEventRecordEntry.recordId

BAAS

Add

  • Add feature flag for detailed metrics by predicate and include warning with usage of high cardinality
  • Add prometheus metrics for badger compactions
  • Add support for Regexp Comparison [no Indexes] in GraphQL Queries and Filters

Change

  • Change etcd/raft to v3

Fix

  • Fix batching of running mutations in one transaction
  • Fix incremental proposal key for zero proposals by changing to incrementing value instead of random value
  • Fix missing badger metrics by removing v3 from expvar lookup
  • Fix supercompose by adding regexpcompare to DgraphIndex enum across schema files

Core

Change

  • Change build pipeline to use v3 specific docker-compose for end-to-end tests
  • Change to align with v3.3.0 schema
  • Change rhize-go library to v3.3.0

Agent

Change

  • Change to align with v3.3.0 schema
  • Change rhize-go library to v3.3.0

Audit

Change

  • Change rhize-go library to v3.3.0

Keycloak Theme

Releasing in step with other components.

Router

Releasing in step with other components.

Compatibility

Rhize v3.3.0 has been tested to work with the following third-party applications:
  • Apollo router 1.61.0
  • Grafana: 9.4.7
  • Keycloak: 21.1.2
  • Keycloak Postgres: 15.3.0
  • Loki: 2.9.12
  • NATS: 2.10.25
  • Tempo: 2.7.1

Checksums

When you install, check the container images against these checksums:

Admin:
registry.gitlab.com/libremfg/frontend/libre-admin-ui:v3.3.0
sha256:47213ad795943761b38ed6ffb27d771287b6b0f6724eedd36e69b5a319300146

BAAS:
registry.gitlab.com/libremfg/baas:v3.3.0
sha256:479c2362da7aed9b50100773eaad59330a7d0b4754e7ffba3a16b3eaf78ffa53

BPMN Engine:
registry.gitlab.com/libremfg/bpmn-engine:v3.3.0
sha256:4bd425794731ee608e7328c3dc57805178607550caa1ef22d91532c3ebe1ca14

Libre Core:
registry.gitlab.com/libremfg/libre-core:v3.3.0
sha256:347e6bb3bf78a0605092faba7d2c915b051bd77802dc8d38d1a007291390d36b

Libre Agent:
registry.gitlab.com/libremfg/libre-agent:v3.3.0
sha256:03659b354f186a17e00048c3412191619200b0471dec74fe269f0f13b8e2bb2f

Libre Audit:
registry.gitlab.com/libremfg/libre-audit:v3.3.0
sha256:1b47df721f8101a293b021a124ad5c048270339a3293bd7f8345fe5abcc7a5af

Libre Audit Postgres:
registry.gitlab.com/libremfg/libre-audit/postgres:v3.3.0
sha256:31ee2bcce47ae027a583aa375bf3a944e67f81501a875f006b1b615d7486a385

Libre Keycloak Theme:
registry.gitlab.com/libremfg/frontend/libre-keycloak-theme:v3.3.0
sha256:3e4f19b7ee01e805f6e3a0660b9af27295e0a8fc8959031e1339b032cfc4b266

Libre Router Init:
registry.gitlab.com/libremfg/libre-router-init:v3.3.0
sha256:808013cb3c99f8ff5c900a8c8bc8b547f3b321cd6af02fa9fc54080dd4c5c6e6

Download v3.3.0-checksums.txt

Upgrade

To upgrade to v3.3.0, follow the Upgrade instructions.

Schema Breaking Changes

Filter changes on high-cardinality types

Transactional entities (E.g. OperationsEvent, and JobResponseData) can have millions of records. Storing full-text, and regex index on these fields becomes storage prohibitive. The new regexpcompare filter offers the same functionality—but without indexing so it’s computed at query time. For implementations replace all usages of regexp with regexpcompare on these types. Since regexpcompare is not indexed, pair it with a high-selectivity filter first (e.g., effectiveStart: { gt: "..." }) for acceptable performance.

This affects:

  • JobResponse.id
  • JobResponseData.description
  • JobResponseData.id
  • JobResponseData.label
  • JobResponseData.value
  • OperationsEvent.id
  • OperationsEventRecord.description
  • OperationsEventRecord.id
  • OperationsEventRecordEntry.id
  • OperationsEventRecordEntry.recordId

ProcessSegment Specific resource Specifications

<RESOURCE>Specifications were previously used for OperationsDefinitions, ProcessSegments and WorkMasters and WorkDirectives. This led to lots of relationships on a <resource>Specification and ambiguous specifications. This breaking change introduces a new Specification type, Segment<resource>Specification to be used with Process Segments. Prior relationships to a ProcessSegment have been removed and the new SegmentSpecification` has been added.

Update implementations to use Segment<resource>Specification.

Before upgrading, export existing relationships to ProcessSegmentSpecification as they’ll be lost after migration. Then import to update.

OperationsDefinition self-relationship name change.

The relationship names for a OperationsDefinition to itself have changed from children, parent to defines, definedBy respectively. Check for usage and if used, query out all the relationships, store them, and then re-implement once your schema is updated.

TestSpecification to relationships swapped

  • The hasInverse relationship on TestSpecification to an EquipmentSpecification, PersonnelSpecification, PhysicalAssetSpecification and MaterialSpecification for the tests<RESOURCE>Specification and testedBySpecification` has swapped to align with the description.

Snippet of change for the relationships between a PersonnelSpecification and a TestSpecification

type TestSpecification {
...
--- requiredByPersonnelSpecification: PersonnelSpecification @hasInverse(field: testedBy)
+++ requiredByPersonnelSpecification: PersonnelSpecification @hasInverse(field: specifiesTests)
...
}
 type PersonnelSpecification {
...
--- testedBy(filter: TestSpecificationFilter, order: TestSpecificationOrder, first: Int, offset: Int): [TestSpecification] @hasInverse(field: requiredByPersonnelSpecification)
---	specifiesTests(filter: TestSpecificationFilter, order: TestSpecificationOrder, first: Int, offset: Int): [TestSpecification] @hasInverse(field: testsPersonnelSpecifications)
+++	testedBy(filter: TestSpecificationFilter, order: TestSpecificationOrder, first: Int, offset: Int): [TestSpecification] @hasInverse(field: testsPersonnelSpecifications)
+++	specifiesTests(filter: TestSpecificationFilter, order: TestSpecificationOrder, first: Int, offset: Int): [TestSpecification] @hasInverse(field: requiredByPersonnelSpecification)
...
}

Change Cardinality of Workmaster defines and definedBy

A work master can define multiple other work masters, yet a work master can be defined by only one. The schema was previously the opposite. Check that your definedBy field aggregate count is not greater than 1. If so, reduce the set to 1 before applying the new schema.

query{
  queryWorkMaster{
    id
    aggregateDefinedBy{ count }
    definedBy { id }
  }
}

Test Specification Physical Sample

The Test Specification physicalSample field is now required. Please update implementations and set to false if unused.

After the new schema has been deployed, the following graphql mutation can be used to set all Test Specifications that don’t have a physicalSample set to false:

mutation {
  updateTestSpecification(
    input: {
      filter: { not: { has: [physicalSample] } }
      set: { physicalSample: false }
    }
  ) {
    testSpecification {
      id
      physicalSample
    }
  }
}
3.2.3