Why status is not a channel¶

The channel's inventory records a status against every artefact version: supported, legacy, untested. It is natural to want to resolve against those — Ref{Name: "onnxruntime", Status: "supported"} — the way you would track a stable channel or a latest tag.

This package does not offer that, and the refusal is deliberate.

The failure it avoids is silent¶

Every artefact in the channel is correctly signed. That is what the channel is for.

So if supported moved from 1.28.0 to 1.29.0 overnight, your tool would resolve 1.29.0, verify the signature, verify the digest, and load it. Every check passes, because every check should pass — the new artefact is genuinely published by the estate.

What changed is which artefact your tool is running, and nothing anywhere reports that. Not the verification, which succeeded. Not your build, which did not change. Not your tests, which ran against a different binary yesterday.

A floating pointer converts "which version am I running" from a fact in your repository into a fact about when you last started the process. For a dependency that is a native runtime with its own ABI, that is a bad trade.

The general form¶

The property is not specific to artefacts: a moving pointer resolves to something correctly signed, so verification cannot tell you it moved.

Signing proves provenance. It says nothing about identity over time. Any system that combines "verify the publisher" with "ask for whatever is current" has this gap, and the gap is widest exactly where the verification looks strongest.

What the labels are actually for¶

They are advisory, and their audience is human:

• supported — what the estate recommends for new work
• legacy — still published, still consumed by something, not recommended
• untested — mirrored but not exercised

They belong in a merge request discussion, a dependency review, an upgrade decision. They answer "should I move to this?" — a question with a person on the other end of it, at a moment when a bump is being reviewed.

They do not answer "what should I load right now", because that question should not be asked at runtime at all.

What to do instead¶

Pin a version. Put it in a constant, so the bump appears in a diff and runs through CI.

To find out what is available, read the inventory in the artifacts project — or call client.Manifest(ctx, ref) for a specific version, which tells you which platforms exist without downloading any of them.

The honest counterargument¶

Pinning has a real cost: a security fix in an artefact does not reach consumers until each one bumps. A floating pointer would propagate it immediately.

That trade is accepted here for two reasons. Artefact versions in this channel are native runtimes and models — things whose behaviour changes with the version in ways a test suite is meant to catch, not things where the newest is automatically the safest. And the propagation problem has a better answer than a floating pointer: Renovate raises the bump as a merge request, which is propagation with a diff and a pipeline attached.

If a floating pointer is genuinely right for some future artefact class, the place to argue it is a spec against the channel — not a resolver option that would apply to everything.