Changelog

0.11.0-alpha.1, 2026-10-17

Each workspace can now run a model of its own and move to a new version on its own.

Releases are numbered by plan, not by date, so a higher number can ship before a lower one. All releases

Full changelog

Interim release, published 2026-10-17. This release was not tagged in the repository. This is the changelog's own text for the release; its links to files point at those files at the tag.

Each workspace runs a model of its own, released on its own (D12): everything since 0.10.0, Base 0.11 packages P0, M1 (with M2), M3, M4, M5, M6 and M6a. Moving a workspace's data to another release (Track V) and data between workspaces whose models differ (Track X) follow in 0.11.0. One migration since 0.10.0 (20261018_01, a release per workspace); a database of 0.10.0 upgrades on start.

Added (0.11 M6a)

  • X-Expected-Model-Release-Id, an optional request header on every management route: a request naming a release its workspace, change set or publication no longer resolves is refused with 409 MODEL_RELEASE_CHANGED before anything is read or written. The browser sends it on its data writes; a page built before its workspace's model changed shows the refusal and a toast with Reload instead of saving under the new release.
  • The API exposes X-Model-Release-Id to browsers on other origins.

Added (0.11 M6)

  • test:browser:workspace-m6: the workspace-model checkpoint, J36 composed in the browser on two generated models beside the starter.
  • The workspace-model surfaces of M5 and M6 in the accessibility and visual gates, light and dark.

Changed (0.11 M6)

  • Settings › Model is laid out as Settings › Workspaces: the models in a list (the default workspace's first) beside the selected model's card with where it runs, its releases and its drafts. A redesign is planned for 0.14.
  • "Activate a release…" is "Change model…"; its dialog groups the releases by model, the workspace's own first, and preselects nothing in another model.
  • The top bar shows the default workspace's model's product name on every page, whatever model the shown workspace runs.

Fixed (0.11 M6)

  • On a phone, choosing a workspace from the band by tapping did nothing; only the keyboard switched.
  • On the "not in this workspace's model" page the sidebar marked a collection as current; a workspace switch read the sidebar's collections twice.
  • test_boundaries::test_tiers_hold failed on an import cycle in the source-file dry run; a model lifecycle test passed only after the tests before it.

Added (0.11 M5)

  • The browser follows each workspace's model: switching workspace changes the applications, navigation and pages to that workspace's model, with a toast when the model or release differs; the workspace selector names each workspace's model and release and marks another model or release.
  • A page saying what an address asks for that the workspace's model lacks, with the workspaces whose model has it; the same for an unknown workspace and one whose release cannot be loaded.
  • Settings › Model shows the workspaces with their models and releases, the installed releases by model with the workspaces running each, and the drafts; a release is activated into one workspace from that workspace's row or the release's page, checked against that workspace's data alone.
  • Settings › Workspaces creates a workspace on another installed release; the model editor's Install and activate puts the release into an existing or a new workspace.
  • releaseName on a workspace's model (workspace responses, its model route, GET /workspace-models, an activation's answer); workspaceKey on GET /model-releases/{id}/diff, whose compatibility and consumerContracts then describe activating into that workspace.
  • test:browser:workspace-m5.

Changed (0.11 M5)

  • An address naming an application the workspace's model lacks no longer opens the start page silently; it says so.
  • A job's page and toasts name types under the job's own workspace's model; the model editor's preview reads records only from a workspace running the draft's model; the load into a change set compares the draft with the release its chosen workspace runs.
  • A release's page shows which workspaces run it and checks it against each workspace of its model; its Activate opens the activation dialog. The single "Active" release is gone from Settings › Model.

Added (0.11 M4)

  • GET /objects takes workspaceKey repeatable: two or more read those workspaces' live records in one paged list, each under its own workspace's model. A type or application some of their models lack is refused 422 MODEL_ELEMENT_NOT_IN_EVERY_MODEL, naming those workspaces; a change set or publication with several workspaces is 422 WORKSPACE_CONTEXT_MISMATCH.
  • Every item of GET /objects names modelReleaseId, the release it was read under.

Changed (0.11 M4)

  • Counterparts stand only between workspaces running one model: an item or file row naming a record of a workspace running another model is refused COUNTERPARTS_ACROSS_MODELS (with the workspace and both model keys), and the import's notice says so, instead of loading it as this workspace's own record under a model it does not belong to.

Added (0.11 M3)

  • Import profiles belong to a model: modelKey on every profile, workspaceKey on its create, update, read and list, and the list's modelKey filter. A profile is refused (422 IMPORT_PROFILE_MODEL_MISMATCH) when saved, imported with or given a file in a workspace running another model, and reads there as not valid with that problem.
  • Draft compilation and the release diff report compatibility.workspaces: what activating would need in each (not retired) workspace running the candidate's model, against its own release.
  • The consumer API index and each OpenAPI document take workspace and answer RDM-Workspace and X-Model-Release-Id; the index's document links carry the workspace. The API reference page (/docs) takes ?workspace=.

Changed (0.11 M3)

  • A draft is compared with its base release, or without one with the newest installed release of its own model, or with nothing when it is a new model (every element added, no consumer contracts, no data impact). A draft-only operation's impact counts only the workspaces running the draft's model. The top-level compatibility is what activating into the default workspace would do.
  • Installing a draft whose profile key another model's profile holds is refused before anything is installed (409 IMPORT_PROFILE_MODEL_MISMATCH); installing no longer runs an unused compatibility analysis.

Added (0.11 M1)

  • Each workspace runs a model release of its own (ADR-042): GET /workspaces/{key}/model, GET /workspace-models (by model or release, paged), modelReleaseId on POST /workspaces, and a workspace's model on every workspace response. Two workspaces may run two different models.
  • POST /workspaces/{key}/model/activation activates a release into one workspace: the compatibility check counts that workspace's data alone, the contract check compares with its release, only its subscriptions are suspended and its matrix states resynchronised; the answer lists its change sets left on the previous release (changeSetsLeftBehind).
  • Every read and write resolves its workspace first, then that workspace's release: GET /model adds RDM-Workspace; a live write naming a record runs under the record's workspace model; jobs, batches, source files, consumer reads, subscriptions and webhook delivery under their workspace's. Unique values follow each workspace's release (D28).
  • GET /model-releases: assigned and workspaces per release and the assigned filter (D24); activations name their workspaceKey.

Changed (0.11 M1)

  • The commit guard checks each workspace a write resolved, under a share lock on that workspace's assignment row: 409 MODEL_RELEASE_CHANGED names workspaceKey, resolvedReleaseId and currentReleaseId. CHANGE_SET_MODEL_RELEASE_CONFLICT names the workspace.
  • A release this version cannot serve makes only the workspaces running it unavailable (503 MODEL_REGISTRY_UNAVAILABLE with workspaceKey, releaseId, schemaVersion); /health is 503 only when no workspace can be served (D29, D34).
  • Settings › Model reads and activates the default workspace's model; Load into a change set activates the release into the workspace it loads into.

Fixed

  • Leaving a change set (discard or publish) left its confirmation as a notice above every page until the browser reloaded; it is now a toast, shown once and dismissable (reported 2026-10-15).
  • Opening Settings reshaped the top bar: a way back was inserted after the product mark, shifting the application tabs, and the Settings icon became a wider "Settings" tab. The bar is now the same on every page: the Settings icon keeps its place and width and is marked current by the tabs' ink underline, and Settings has no way back of its own (the product mark and the application tabs leave it) (the user, 2026-10-15).

Removed (0.11 M1)

  • GET /model-runtime-state, POST /model-releases/{id}/activation, the active field and filter of GET /model-releases. Migration 20261018_01 gives every workspace the release the instance ran (version 1) and drops model_runtime_state and model_releases.is_active.

Planned (0.11 P0)

  • Base 0.11's design pass: each workspace runs a model of its own (ADR-042), with the decisions D4–D29 and the inventory of what a move between models meets accepted; the API design for a workspace's model, activation into one workspace, migrations, mappings between models and moves (API.md § Workspace models); journeys J36–J38; mock-ups of the shell and Settings across workspace models and of the move editor.

Let us run it for you.

Backups, upgrades, TLS and monitoring are ours. Your data stays exportable any time.