Examples
Complete, copy-ready release setups, one page per ecosystem and one per delivery target, each with the config, the
scripts its stages run, and the terminal output of a real run. Every dispat transcript in this section was produced by
running dispat against a throwaway repository; only timestamps and durations are normalized. Lines printed by your own
commands (the npm, docker, butler lines) come from those commands, so yours will differ.
You do not need a monorepo to start. One folder, one package, one publish is a valid setup, and growing into a graph later is additive: no restructuring, and the versions already published stay the baselines everything counts from. That matters because a repository holding one deliverable rarely keeps holding one. A game gains a landing page, a docs site, an SDK and a server; a library gains a CLI and a demo. Each of those is one more block in the same file rather than one more release script nobody maintains. A single package is the smallest form, and A game, from one package to many walks the growth step by step.
If a term is new, Concepts defines all of them in a few minutes of reading, and One repository or many is the page for deciding the shape before you commit to it.
Read one page, then one more. An npm monorepo is the shortest complete setup and the best first read whatever you build, because every other page is the same four pieces with different commands in them. After that, go to the page for your own ecosystem below. If you are bringing dispat to a repository that already ships versions, Adopting dispat is the second read instead.
Ecosystem by ecosystem
One page per package manager, each with a config you can copy, the scripts its stages run, and a real run.
| 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. |
Game development
| Example | What it covers |
|---|---|
| A game, from one package to many | One game today; a landing page, docs, an SDK and a server later. Godot and Unity. |
| 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. |
| 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 are about one ecosystem each. These are about the repository around them, and they apply 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-five manifest formats. Every one of them is worked through on one of 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, project.json, gem.json | Games |
A version that lives in none of these, a Helm Chart.yaml, a README install line, a plain text file somewhere, is
handled by the replace strategy and worked through on the
Helm page.
The pages under Editing the monorepo are the other half of the worked examples: the commands that change files across many packages between releases. How a release behaves once it covers more than one package is under Releasing, starting with shared versions, and the CI side is under dispat in CI.