Framework release and publication commands

The framework publishes itself with commands rather than with a document someone follows. One version is set once and synchronised into the framework marker and every managed package manifest; the package publish derives its own ordering from the dependency graph; the image publish builds and pushes the declared images under an immutable tag. What gets published is declared in the framework configuration, so the release set is reviewable rather than remembered.

The problem it solves

A framework that ships as several dozen interdependent packages plus a container image has a release that is mostly bookkeeping, and bookkeeping done by hand goes wrong in ways that are expensive downstream. Versions drift apart between manifests. Packages get published in an order where a consumer briefly resolves a version of its dependency that does not exist yet. A prerelease lands on the default distribution tag and reaches every consumer running a plain install, which cannot be withdrawn, only superseded. An alias tag is repointed at an image whose push then fails.

The other half is subtler and specific to a framework built as one workspace. Inside the repository every package declares its third-party dependencies as a wildcard and the real version is pinned once at the root, which is correct for a workspace and meaningless to a consumer, who has no such root. The published manifest has to say something concrete, and what it says has to be derived from that one pin rather than typed a second time.

What it does

Releasing the framework is a sequence of commands: set the version once, write it everywhere, publish the packages, publish the images.

The version has one source. Setting or bumping it establishes it; a sync writes it into the framework marker file and into every managed package manifest.

Publishing packages stages a publishable manifest for each declared package, and materialisation is where the workspace wildcard becomes a real range: the root pin is substituted in, exactly for ordinary dependencies and widened for peers — so a consumer keeps the tested version as a floor without inheriting an override it has no way to express.

Publication order comes from the dependency graph, and a cycle is refused rather than published in an arbitrary order. A prerelease version with no explicit distribution tag is refused outright, because the default tag is what a bare install resolves.

Publishing images builds each declared image and pushes it under an IMMUTABLE tag, defaulting to the framework version — and a channel that publishes per commit supplies its own tag instead, because on that channel the commit rather than the version is what makes the artifact unique. Mutable aliases are repointed afterwards, and only after every immutable push has succeeded, by pointing the alias at the published manifest rather than by rebuilding.

Both publish commands support a dry run that prints the exact commands they would execute, and the registry host and namespace are pinned in code, so a framework configuration naming a different pair is refused.

What you decide

The declared publish set lives in the framework configuration, so adding a package or an image to a release is an edit there rather than a flag on the command.

Limits

The combined publish command is a planning command only. It requires a dry-run flag and exits non-zero without one — coordinated cross-registry release orchestration is not wired, so a real release runs the two commands separately.

There is no publish pipeline. The release lane runs from a developer machine, and the framework’s container credential is the one for its registry of record. That is recorded in the release constants as the reason a move to a different registry was reverted, rather than as an aspiration.

The framework version is synchronised across managed framework packages only. The example applications sit outside that surface and carry their own versions.