A release dependency means one release cannot safely ship, or work, until another has. They are usually known to someone and written down nowhere, so they surface at deploy time. The fix is to make them visible before the release, not remembered during it.
A release dependency exists when one release cannot safely ship, or cannot work correctly, until another release (or a change in another service) has shipped first. It may be a library or API a service needs, a database migration, a configuration or infrastructure change, or simply an order the teams agreed. A hard dependency blocks the release; a soft dependency is advisory.
A hard dependency blocks: if the upstream release has not shipped, this one should not. A soft dependency advises: it is better to ship the upstream first, but not shipping it does not break anything. Treating every dependency as hard grinds delivery to a halt; treating every dependency as soft means the ones that matter get missed.
When an upstream release slips, everything downstream either waits or ships without what it needed. Knowing the graph ahead of time turns that from a surprise at the deploy window into a planned resequencing.
ArcRelease draws the Release Dependency Map from the links your teams already maintain, marks hard and soft dependencies, and includes an upstream-dependencies check in every release preflight, so a release whose upstream has not shipped fails that check before the deploy window, not during it.
One release needing another to have shipped first, whether because of code, an API, a data migration, configuration or an agreed order. If the upstream has not shipped, the downstream release may break or must wait.
A hard dependency blocks the release: it should not ship until the upstream has. A soft dependency is advisory: the order is preferred, but the release is not broken without it.
Start from the tracker links and fix versions your teams already maintain, read pull requests for the services each change touches, and ask the owners of shared schemas, APIs and infrastructure what depends on them. Then keep the result somewhere everyone reads.
Identify every release that depends on it, decide whether each waits, is re-scoped or ships without the dependency, and record who decided. The earlier the graph shows it, the more options you have.
Often, in part. Backward-compatible APIs, expand-and-contract migrations, feature flags and independent deployability all reduce how much the order matters. What remains still needs to be visible.
ArcRelease is advisory and never in the deploy path. It shows the dependencies, fails the upstream-dependencies check in the preflight when an upstream has not shipped, and records any decision to ship past that failure as a signed statement with evidence.
Tell us about your release process. Connect your stack in ten minutes, run a Gaja preflight on a real release, and see the reasons behind the verdict.
Free plan · ten minute setup · we reply in one to two business days