A release that does not ship still needs an outcome

A release enters the queue, passes several checks, and then ships nothing. A newer build replaces it. The product team changes the rollout decision. A destination becomes unavailable. An operator notices that the artifact is valid but no longer wanted.

Nothing shipping can be the correct result. The operational mistake is leaving the run in a vague state that looks failed, forgotten, or still in progress.

We treat no release as an outcome that needs the same identity and ownership discipline as a successful submission. The record should explain what stopped, who made the decision, which proof remains valid, and what may happen next.

Cancellation is not one state

Cancelled is often used for several different facts. The release may have been withdrawn before any store or deployment action began. An in-flight operation may have received a cancellation request. A completed upload may have been left unpromoted. A newer release may have made the original one irrelevant.

Those outcomes carry different risks. A pre-flight withdrawal should not imply that remote side effects might exist. A cancellation request sent after submission began should not imply that the provider obeyed it. A superseded artifact may still be perfectly buildable even though it should never ship.

One terminal label cannot carry all of that. Keep the decision separate from the observed execution state. The team can then say both that a release is no longer intended to ship and that a remote submission remains unknown.

Record the reason as evidence, not theatre

The outcome needs a concise reason tied to the decision available at the time. Superseded by release 842, store destination unavailable, or rollout withdrawn by the release owner is more useful than aborted or manually stopped.

The record should not invite a long defence. Operators under pressure tend to produce either empty notes or speculative narratives when a workflow demands an essay. A structured reason, an optional bounded note, the actor, and the timestamp usually preserve what the next person needs.

Automation can supply facts it actually knows, such as the replacing artifact or the failed destination check. It should not invent the human reason. When intent is unknown, say that plainly and assign the unresolved decision to an owner.

Keep completed proof attached

A no-release outcome should not erase work that was already proved. Build identity, signing checks, test results, and artifact metadata may still matter for incident review or for understanding what the replacement changed.

At the same time, inherited green checks must not make the abandoned release look eligible to resume automatically. Preserve the proof with its scope and age, then require a fresh admission decision if anyone later wants to reactivate the artifact.

This distinction saves time during review. The team can see that the release did not ship because it was deliberately superseded, not because the build failed. They can also see which checks a future release may reuse and which depend on a destination or configuration that has since changed.

Reconciliation comes before closure when side effects started

If an external submission may have begun, the workflow cannot close honestly on intention alone. It needs to reconcile the remote state or preserve an explicit unknown with a lookup path.

For example, an operator may withdraw a release after an upload request times out. The desired outcome is clear, but the provider may still have accepted the binary. Marking the run cancelled without checking would hide a possible artifact that still needs review or removal through the provider's normal controls.

The durable outcome can therefore be no longer approved to ship, remote submission unknown, reconciliation owned by a named person or process. That is less tidy than cancelled, but it gives the next operator a truthful starting point.

Make deliberate non-shipping visible in release history

Release history should include successful deployments, failed attempts, and deliberate decisions not to proceed. Hiding the third category makes teams misread healthy restraint as unreliable delivery.

A useful history view answers four questions quickly: which artifact was considered, how far execution reached, why shipping stopped, and whether any follow-up remains. It should be possible to distinguish a clean supersession from a broken pipeline without opening raw logs.

Ubriot is built around accountable mobile release work. That includes respecting the decision not to ship. A release that ends safely before production is not missing data. Give it a precise outcome, preserve what was proved, and leave no remote uncertainty without an owner.