A construct changes underneath you
Component types and traits are versioned objects with consumers. What happens when one moves, how to see what adopting a version would change, and why your release was re-cut without you asking.
A ClusterComponentType or ClusterTrait is a construct: the platform's
offer to an application. It has a version, it has consumers, and editing it
changes every one of them.
Component types, traits and resource types, each with who uses it.
The construct catalog →
A release freezes the construct, not a reference to it
This is the fact that explains most surprises here. When a ComponentRelease is cut it embeds the entire component type and trait bodies it resolved against — not a pointer to them.
Two consequences:
- A release is reproducible. What ran in production last week can be rendered again exactly, because nothing it depended on can move underneath it.
- Editing a construct re-cuts every consumer, with no change to any image, and nobody asked for it.
That is why a build page can list several releases carrying the same digest.
They are grouped as "later releases from these same bytes", and each names the
construct that moved. bakery-web has eleven on one digest — four within
twenty-two seconds, a version going 1 → 1.1 → 1.1.1.
Seeing what a version would change, before adopting it
Two versions side by side, field by field: what a consumer would gain, lose or have redefined.
Pick a construct, then Compare →
This is the question the catalog exists to answer. "Version 2.0.0 is available" is not actionable; "2.0.0 removes the field your component sets and adds a required one" is.
Pins, and the fourth axis
A component can pin a construct version, and a pin can be a range. That matters more than it sounds:
A component pinned to version: "2" is satisfied by 2.0.0. Compared with ==
it is not, and the catalog once reported "Used by 0" for a construct with real
consumers — the page looked healthy and the number was silently wrong.
The trait screenshots in shots-traits.txt exist as the regression detector for
exactly that bug.
Which is what these two show. The same trait, two versions, and the count that was once wrong:
And the comparison between them, which is the page that makes a version bump actionable rather than merely announced:
What is behind upstream
Every pinned thing on this platform against what upstream has published.
Upgrade watch →
Four axes, and the fourth is the one people forget: container images, Helm charts, language dependencies — and the platform's own constructs. A component type nobody has revisited is as much a pin as an image tag.
Construct versioning here is one type deep: forty-two of the forty-three live constructs declare no version at all. That is a real gap and the page reports it as one rather than rendering an empty column that looks fine.