FMR 12 Release Notes¶
Fusion Metadata Registry 12 introduces a set of changes aimed at both day-to-day registry operations and longer-term platform scalability. This release strengthens auditability and governance through metadata time travel and semantic versioning, broadens enterprise integration with modern authentication options, and improves performance for registries managing larger and more complex metadata estates.
For technical readers, FMR 12 adds support for new SDMX capabilities, more flexible security integration, and an architecture designed for higher metadata volumes. For business and programme stakeholders, the release improves traceability, reduces operational risk, and supports growth without a corresponding increase in memory demand.
New features¶
Metadata time travel¶
FMR 12 records the history of changes made to every artefact, making it possible to query structures exactly as they existed at a specific point in time. This capability is exposed through the SDMX structure REST API v2.2.0 asOf parameter.
Get the latest versions of all codelists as stubs as they were at 16:00 UTC on 12 April 2026:
https://example.registry.com/sdmx/v2/structure/codelist/*/*/~/?format=sdmx-3.0&detail=allstubs&asOf=2026-04-12T16:00:00Z
Time travel also works with reference metadata reports.
Get the metadata report ABC:REPORT1(1.0) as it was at 09:00 UTC on 15 July 2026:
Typical use cases include:
- validating datasets against the structural metadata that was in force when the data were created
- supporting audit and compliance requirements
- debugging change histories and identifying when a specific update was introduced
Semantic versioning¶
FMR 12 implements the SDMX 3.1 semantic versioning specification together with the versioning rules defined in the TWG/SWG semantic versioning guidelines. This gives organisations a clearer and more predictable way to manage change, especially where metadata structures are shared across teams or external consumers.
Maintain semantic and non-semantically versioned structures in the same registry
Immutable artefacts: structures with semantic version numbers can only be changed by creating a new version
Wildcard cross referencing
Automatic detection of the scope of changes and application of versioning rules; for example, deleting codes from a codelist is identified as a breaking change and forces a new major version
Handling of draft structures identified by the _draft suffix
Handling of zero-versioned structures, which are considered draft by default
OIDC authentication¶
The authentication subsystem has been reengineered to support multiple authentication methods, making FMR 12 easier to align with enterprise security standards. The release adds OpenID Connect (OIDC) support for both interactive users and machine-to-machine integration.
- Supports OIDC authentication for both interactive users and machine-to-machine clients
- Supports the OAuth 2.0 authorisation code flow for interactive access, with or without PKCE
- Supports the OAuth 2.0 client credentials flow for machine-to-machine access
FMR 12 now supports five authentication approaches:
- Internal superuser account: FMR's built-in authentication service provides a single
rootsuperuser account created during installation - OpenID Connect (OIDC): for environments where identity is managed by an OAuth 2.0 identity provider (IdP)
- Directory services: for environments using Microsoft Active Directory (AD) or a generic LDAP directory service
- Custom security services: for authentication mechanisms such as CAS or SPNEGO supported by Tomcat authentication valves
- X.509 client certificates: for interactive users or machines authenticating with a client certificate
FMR 12 integrates with major OAuth/OIDC identity providers including Microsoft Entra ID and Keycloak.
Lower memory usage and support for 'big metadata' use cases¶
FMR 12 introduces an updated content storage approach to support significantly larger metadata estates while reducing platform memory demand. FMR 11's pure in-memory model has been replaced by a more sophisticated strategy that uses the database as the primary store, reducing the dependency between deployment memory and registry size.
- Platform memory demand no longer scales linearly with registry content
- Designed to support "big metadata" scenarios with both large structures and high volumes of artefacts
- Provides a stronger foundation for semantic versioning, where immutable structures require a new version for each change
Testing indicates that platform memory of 16GB should be sufficient for many production use cases.
Like Redis, FMR 11 was designed as a pure in-memory model to maximise retrieval performance for metadata driven processes. It also assumed that the volume of metadata would remain relatively compact. That assumption no longer holds true. Moreover, metadata caches now solve the retrieval performance problem. Thus FMR 12 sacrifices a bit of retrieval performance in return for a lower memory footprint and importantly avoids the need to scale platform memory in proportion to the content volume.
Migrating content from FMR 11 to FMR 12¶
FMR 12 introduces significant changes to the database schema and and the system configuration parameters. For this reason, it's not possible to to directly upgrade an existing FMR 11 installation to version 12. Instead a separate FMR 12 installation must be created with an empty database and the content migrated.
The recommended content migration method is to use the backup and restore process which importantly:
- preserves the structure change history and audit records;
- copies reference metadata reports (aka metadatasets); and
- copies data registrations
On import, FMR 11's change history is reorganised into FMR 12 metadata time allowing past registry states to be queried using the metadata time travel feature.
Behaviour changes between FMR 11 and FMR 12¶
Structure query using '+' and '~' version wildcard operators¶
FMR supports the SDMX v2.0+ structure query REST API, including semantic wildcard queries for version selection using the + and ~ operators.
Examples:
GET https://registry.example.org/sdmx/v2/structure/codelist/ACY/CL_REF_AREA/1.0+.0
GET https://registry.example.org/sdmx/v2/structure/datastructure/ACY/BOP/2.1.0~
The first query asks for the latest stable minor version compatible with 1.0.0 of the CL_REF_AREA Codelist. The second asks for the latest version of the BOP DSD starting from 2.1.0 irrespective of whether this is stable or unstable.
Warning
FMR 12 will no longer return two-part versions when using the + latest operator.
In FMR 11, the + operator returns the latest version of the structure irrespective of whether this is a two (e.g. 1.0) or three-part (e.g. 1.0.0) version number.
FMR 12 now conforms precisely to the SDMX spectification, notably:
+returns the latest stable version of the structure~returns the latest version of the structure whether stable or not- The version path parameter defaults to
~if not specified - Two-part versions are treated as unstable
Thus the ~ operator must now be used when querying for the latest structures with two-part versions.