4.5 KiB
Release Validation Matrix
The shared unattended and physical campaign contract is defined in VALIDATION_CAMPAIGNS.md.
This matrix defines what release automation should ask the maintainer to validate. It is a target for the v0.4 automation, not a claim that all runners are already implemented.
Profiles
| Profile | Purpose | Typical runtime |
|---|---|---|
quick |
Import, ABI, C consumer, and one render smoke from installed artifacts. | Minutes |
rc |
Required release-candidate validation for a supported machine. | Tens of minutes |
full |
Broader examples, docs snippets, Vulkan validation, and selected live smoke. | Longer/manual |
manual |
Human-guided live examples and interaction checks. | Maintainer-driven |
Required Machine Classes
The exact machine names are maintainer-local. Each class should have one stable machine_id in the
evidence bundle.
| Class | Required for RC | Required for final | Main proof |
|---|---|---|---|
| macOS Apple Silicon | yes | yes | arm64 wheel install, offscreen render, live app smoke, optional Qt/PyQt |
| macOS Intel | yes if available | yes if available | x86_64 wheel install, native dependency inventory, import/render smoke |
| Linux x86_64 with Vulkan GPU | yes | yes | manylinux wheel install, Vulkan validation, C/Python examples |
| Linux aarch64 | artifact required, execution if available | artifact required, execution if available | wheel inventory and native execution when a host exists |
| Windows AMD64 | yes | yes | wheel install, datoviz.raw, CMake consumer, Python smoke |
| Windows ARM64 | artifact required, execution if available | artifact required, execution if available | wheel inventory and native execution when a host exists |
RC Profile Checks
The rc profile should run from installed artifacts where possible:
- install wheel or source bundle into a clean environment;
- import
datovizanddatoviz.raw; - run ABI/layout smoke checks;
- run
datoviz-configorpython -m datoviz.cli --cflags --libs --cmake-dir; - compile and run the installed CMake consumer;
- run at least one offscreen render smoke;
- run representative C examples from release metadata;
- run representative Python examples from release metadata;
- capture stdout/stderr and Vulkan validation output when available;
- record skipped optional providers, such as Qt/PyQt, with explicit reasons.
Full Profile Additions
The rc profile includes wheel inventory, installed import/CLI checks, CMake consumer proof, and
installed Python/C no-window example smokes from the candidate wheel. It should run on required
machine classes before accepting the RC.
The full profile may add:
- installed Python/C offscreen render example smokes from the candidate wheel;
- all public C examples that support bounded
--pngor--smoke-msexecution; - all public Python examples classified as automated or smokeable;
- documentation fenced-code doctests;
- gallery capture and media fingerprint checks;
- WebGPU/WASM browser smoke on capable hosts;
- scripted interaction checks for panzoom, arcball, resize, picking, and close-window behavior;
- longer live-loop churn tests;
- Vulkan validation-layer runs for runtime ownership and synchronization paths.
Manual Profile
The manual profile is intentionally short and targeted. Durable requirements live in
PHYSICAL_VALIDATION.md, and the reusable agent procedure lives in
docs/contributors/release-physical-validation.md.
The local agent must launch the selected apps one at a time and ask the maintainer to perform the
stated interaction; it must not hand-maintain an ad hoc checklist.
Manual smoke should cover:
- one simple 2D live app with panzoom;
- one 3D live app with arcball or fly controls;
- one text/annotation/layout example;
- one image or color-scale example;
- one mesh or textured mesh example;
- one picking/query or readback example when supported on that platform;
- resize, close-window, and repeated-open behavior.
Evidence Policy
For each machine class, the report should show:
- artifact installed;
- profile run;
- pass/fail/skip status;
- GPU/driver/runtime facts;
- known issues or exclusions;
- capture artifacts when available.
The release report must not infer support from an artifact existing. A wheel build proves inventory; execution proof comes from a native or otherwise trusted runtime evidence bundle.