LabKit MATLAB Workbench

history

Facade contract baseline and release validation hardening

id: LK-20260623-facade-contract-baseline-and-release-validation-hardening
date: 2026-06-23
sequence: 11
type: ci
compatibility: compatible
component: `labkit.biosignal` | `new -> 1.0.0`
component: `labkit.dta` | `new -> 1.0.0`
component: `labkit.rhs` | `new -> 1.0.0`
component: `labkit.ui` | `new -> 2.0.0`
component: `labkit.ui` | `2.0.0 -> 2.1.0`
component: `labkit.ui` | `2.2.0 -> 2.2.1`
component: `labkit_DICPostprocess_app` | `1.0.0 -> 1.0.1`
component: `labkit_DICPreprocess_app` | `1.0.0 -> 1.0.1`
component: `labkit_CurvatureMeasurement_app` | `1.0.0 -> 1.0.1`
scope: Facade contract baseline and release validation hardening

Context

Reusable packages exposed public MATLAB functions, but apps had no machine-checkable way to state which API versions they required. Release and CI checks also needed one consistent build-task entry path.

Decision and rationale

Give each reusable package version metadata and let apps declare compatible ranges that are checked at launch and in tests. Route MATLAB CI shards through the same build tasks used by maintainers so release validation exercises the documented commands.

Changes

User and data impact

An incompatible app/package combination could fail with a direct requirement message instead of producing a later missing-function error. Existing project and result data were unaffected.

Compatibility and migration

The contract metadata described the existing public facades and was additive for app callers. Apps with an incompatible declared requirement now failed at launch with a version diagnostic instead of continuing unpredictably.

Validation

The listed commits introduced contract, lifecycle, and CI build-task tests. Release tags v2.4.1 and v2.4.2 identify the shipped checkpoints; exact local commands were not recorded.

Evidence

Known limitations and follow-up

App and launcher display versions were added in the separate version-metadata change later the same day.