Examples
These pages give you complete, copy-ready release setups. You get one page per ecosystem and one per delivery target. Each page shows the config, the scripts its stages run, and the terminal output of a real run.
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.
This matters because a repository holding one deliverable rarely stops there. A game gains a landing page, a docs site, an SDK, and a server, while a library gains a CLI and a demo. Each addition becomes one more block in the same file rather than another release script nobody maintains.
Read A single package to see the smallest form. Then read A game, 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.
Read one page, then one more. Start with An npm monorepo whatever you build. It is the shortest complete setup and the best first read, because every other page uses the same four pieces with different commands.
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.
Ecosystem by ecosystem
These pages cover one package manager each. They include 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 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-five 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, project.json, gem.json | Games |
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.