Examples
These pages cover release setups by ecosystem and delivery target. Release walkthroughs show their configuration, scripts and terminal output, while manifest-focused guides explain what dispat changes and what remains the native toolchain's responsibility.
Every dispat transcript comes from a real run against a throwaway repository, with only timestamps and durations
normalized. Lines printed by your own commands, like npm, docker, or butler, come directly from those tools. Your
output will look different.
You do not need a monorepo to start. One folder, one package, one publish is a valid setup. Growing into a graph later is additive, so you avoid restructuring and keep your already published versions as baselines.
A library can gain a CLI and documentation; an application can gain a container, SDK and website. Each deliverable can join the same release graph while retaining its own build and publication tools.
Read A single package to see the smallest form. Then read From one package to many to walk through the growth step by step.
Check Concepts if a term is new. It defines all of them in a few minutes of reading. Read One repository or many to decide your shape before you commit to it.
Start with From one package to many for the general pattern, then choose the ecosystem whose commands match your project. An npm monorepo provides a compact complete release setup.
After that, go to the page for your own ecosystem below. Read Adopting dispat second instead if you are bringing dispat to a repository that already ships versions.
Read Integrating an existing release pipeline for build boundaries, artifact checks, recovery and the limits of orchestration. Skills, specifications and TeX documentation covers versioned non-code deliverables.
Python without uv and with Pants covers historical build setups.
Ecosystem by ecosystem
Choose your ecosystem below. Each page distinguishes release walkthroughs from narrower manifest and integration checks, and explains what still belongs to the native toolchain.
| Example | What it covers |
|---|---|
| An npm monorepo | Package scripts, a build and a publish, versions from commits. |
| A pnpm workspace | workspace: ranges, the shared lock file, and pnpm publish mid-release. |
| A Go module workspace | Tag-driven versions, the replace link bracket, and why tagFormat matters. |
| A Cargo workspace | path dependencies, [patch.crates-io] links, and workspace inheritance. |
| A Python monorepo | pyproject.toml and requirements*.txt reconciled in one pass. |
| Maven modules | pom.xml, ${property} skips, and parent-managed versions. |
| A Gradle library and its version catalog | libs.versions.toml, version.ref, and literal coordinates. |
| .NET packages | dotnet pack, project references, and central package management. |
| Composer packages | Versions from tags, and a composer.json with no version field. |
| Ruby gems | Gemspecs, Gemfiles, and the VERSION constant a writer will not touch. |
| A Flutter app and its packages | pubspec.yaml, the +N build number, and dependency_overrides. |
| An iOS app and a CocoaPods library | Info.plist, project.pbxproj, Podfiles and podspecs. |
| An Android app | Gradle, a monotonic versionCode, and a bundle on the GitHub release. |
| A Docker image chain | Images depending on images, where a build needs its base published. |
| Defold projects | Monarch: project versions and archive-URL dependencies. |
| O3DE projects and gems | Atom: gem versions and explicit dependency constraints. |
| Aqua tool pins | Imported tool pins, asset selectors and the provider publication boundary. |
Game development
| Example | What it covers |
|---|---|
| Game development | Engine and store integration, with a link to the general one-to-many guide. |
| Publishing to Steam | steamcmd, depots, and release channels mapped onto Steam branches. |
| Publishing to itch.io | butler, one channel per platform, and the version players see. |
Shipping artifacts
| Example | What it covers |
|---|---|
| Cross-platform binaries | Four targets, checksums, and assets attached to the GitHub release. |
| Helm charts that follow the image | appVersion and image tags written by the run that pushed the image. |
| Terraform before application deployment | Versioned infrastructure, temporary imported state, and dependent backend and frontend deployments. |
| A site deployed from the release | A docs or marketing site published during the run, with a CI-only guard. |
Shaping the repository
The pages above focus on one ecosystem each. The pages below cover the repository around them. They apply to your setup whatever you build.
| Example | What it covers |
|---|---|
| A single package, no monorepo | dispat on a repository with one thing in it, and what changes when it grows. |
| Adopting dispat | Deriving the graph and the starting versions from the manifests, in a new repository or one that already ships. |
| Keeping configuration beside the code | Space and package config files in their own folders, and .dispatexclude. |
| npm and Docker in one graph | Two ecosystems, one graph: the mixed case dispat was built for. |
| Registry login, once per space | The login slot: one authentication per space, whatever the registry. |
Which example covers my manifest
dispat reads and writes thirty-six manifest formats. You will find every one of them worked through on these pages.
| Manifest | Example |
|---|---|
package.json | npm, pnpm |
go.mod | Go |
Cargo.toml | Rust |
pyproject.toml, requirements*.txt | Python |
composer.json | PHP |
pom.xml | Maven |
*.csproj, *.fsproj, *.vbproj, *.nuspec, Directory.Packages.props, packages.config | .NET |
pubspec.yaml | Flutter and Dart |
Gemfile, *.gemspec | Ruby |
Podfile, *.podspec, Info.plist, project.pbxproj | Apple |
AndroidManifest.xml, build.gradle, build.gradle.kts | Android, Gradle |
libs.versions.toml | Gradle |
Dockerfile, Containerfile, compose.yaml | Docker |
Packages/manifest.json, ProjectSettings/ProjectSettings.asset | Unity |
project.godot, plugin.cfg, export_presets.cfg | Godot |
*.uproject, *.uplugin, Config/DefaultGame.ini, Config/DefaultEngine.ini | Unreal |
game.project | Defold |
project.json, gem.json | O3DE |
You might have a version that lives outside these formats, like a Helm Chart.yaml, a README install line, or a plain
text file. The replace strategy handles those. Read the Helm page to
see it worked through.
The pages under Editing the monorepo provide the other half of the worked examples. They show the commands that change files across many packages between releases.
Read shared versions to see how a release behaves once it covers more than one package. Check dispat in CI for the CI side.