PostProject 0.5 compatibility decision¶
This decision applies ADR 0040 to the 0.5.0-alpha.1 release candidate. The
maintainer accepted the no-subset recommendation on 2026-10-01. The generated
Compatibility-family usage evidence report is the mechanical input; this
page records the semantic, projection, and usefulness review that the report
cannot decide.
Decision¶
Release the 0.5 series with no named compatibility subset.
Two leaf families are mechanically eligible, but neither forms a useful compatibility contract without foundational families that lack the required two-host evidence:
flowchart LR
production["production lifecycle<br/>one host"]
transaction["transaction lifecycle<br/>one host"]
identifiers["external identifiers<br/>two hosts"]
resolution["resolution<br/>three hosts"]
production --> identifiers
transaction --> identifiers
production --> resolution
classDef eligible fill:#d8f3dc,stroke:#2d6a4f,color:#081c15
classDef incomplete fill:#fff3bf,stroke:#e67700,color:#3d2800
class identifiers,resolution eligible
class production,transaction incomplete
Promising only the leaf operations would still require consumers to create, open, and release experimental production handles. Identifier attachment would also require an experimental transaction begin/commit/release contract. That is a misleadingly tiny release subset, even though the leaf-family evidence is real.
Candidate review¶
Criterion |
External identifiers |
Resolution |
|---|---|---|
Present in |
yes |
yes |
Complete normal-path host evidence |
Blender, Kdenlive |
Blender, Kdenlive, OpenAssetIO Manager |
C declarations unchanged through the candidate |
yes |
yes |
C++ projections unchanged through the candidate |
yes |
yes |
Python projections unchanged through the candidate |
yes |
yes |
Baseline-path semantics unchanged |
yes |
yes |
Required family members qualify together |
yes |
yes |
Useful dependency closure qualifies |
no |
no |
The declaration review compared the authoritative C header, header-only C++
wrapper, and Python binding at v0.4.0-alpha.1 with the candidate. No included
declaration or projection changed. The resolution implementation changed only
to add behavior-neutral opt-in trace instrumentation.
External-identifier attachment gained semantic-conflict participation for a transaction created through the new base-revision entry point. That entry point did not exist in 0.4 and is not part of the external-identifier family. Calls through the unchanged 0.4 transaction path retain their observable behavior; the additive base-revision path does not revise the baseline contract.
Ardour is not counted as another matrix host. Its executable scenario runs the
same resolver policy compiled into the patched host and proves installed
pkg-config, exception-enabled C++, and audio-content behavior, but it does not
execute the complete operation family through a normal interactive Ardour
callback in this environment.
ADR 0020 amendment¶
The accepted amendment records this release-series decision in ADR 0020:
## Release 0.5 series
Release 0.5 names no compatibility subset. All APIs in the 0.5.x series remain
experimental and may change within the series, with migration notes for
operations used by maintained integrations.
ADR 0040 evidence found the external-identifier and resolution operation
families mechanically eligible across the 0.4-to-0.5 boundary. They are not
named as a compatibility promise because each depends on production lifecycle,
and external-identifier mutation also depends on transaction lifecycle; those
foundational families did not have complete normal-path evidence from two
independent hosts. Publishing only the eligible leaf families would therefore
be misleadingly narrow.
Released production schemas continue to receive tested forward migrations
under the repository's pre-1.0 migration policy. This decision creates no ABI
or schema compatibility promise beyond that policy.
The same outcome is stated in docs/abi-policy.md and the release notes. The
0.5 release report records it as part of the completed release policy.