cidx v2.1.0 — the most useful output of a release was its seven bug reports

cidx is a declarative CI/CD runner I build (in Go) — you describe your pipeline once, it runs the same locally and in CI, exit-code parity guaranteed. v2.1.0 just shipped. And the most useful thing it produced wasn't the tag.

The interesting part of a release is almost never the changelog. It's what cutting the release teaches you.

The short part (the diff)

11 commits since v2.0.0, after 59 quiet days. A probatum test-phase preset, a pr edit action (retitle a PR without dropping to the platform UI), and six fixes: prebuilt cargo-audit (faster security phase), anonymous-pull fallback when a registry 401s on stale creds, pinning the bootstrapped cidx to the version that generated it (no more @latest drift), cpw waiting for the CI workflow to actually start, branch prefixes derived from commit type, and check drift resolving the workflow file instead of guessing .github/workflows/ci.yml. Correct, useful, boring. On to the real story.

Cutting a release with your own tool

cidx can cut a release: cidx release create. So I used it to cut its own. And that's exactly where it gets interesting — a tool on a tidy demo never shows its rough edges; a tool on a real, high-stakes task (tag it, push a version) shows them all.

Seven, that day. Filed same-day, tag still warm:

• #184 — release create pushes the version-bump commit straight to main… and gets rejected by branch protection. Recovery is a hand-rolled PR-then-cherry-pick-then-tag. The tool doesn't know the rules of the repo it runs on.
• #185 — release preview computes the version from three sources (VERSION, .cz.toml, latest tag) with no reconciliation. First run: it suggested v1.8.0 when the latest tag was v2.0.0. A single source of truth was missing.
• #186 — release tag prepare waits on an editor with no TTY detection. It hangs.
• #180 — cpw reports "nothing to commit" for untracked files.
• #178 — cidx's own cidx.toml now has real drift — precisely because fix #177 finally lets check drift see it: docker and release phases declared, no matching jobs in ci.yml. The tool finding its own mismatch.
• #175 — breaking-change detection reads type!: from parsed commits, but the parser regex can't capture the !. Latent bug.
• #174 — ~20 CLI hints still point at the deprecated cidx action … namespace.

None of those show up reading the code. Each is a knot you only feel by pulling on the rope for real.

The loop working, not the loop breaking

cidx's CLAUDE.md states a rule: "we eat our own cooking; if a command has bad UX, that becomes the next priority." v2.1.0 is that sentence in action. The release ships, and the release-tooling backlog grows the same day. That's not a release failure — it's the only honest way to know where the tool hurts: take it seriously on its own most sensitive task.

And here's the nuance. Everyone says "we dogfood — we use our own tool." The honest version is different: you use it on the scary thing, and you write down, publicly and same-day, every place it bit. The rough edges aren't swept under the rug waiting for a user to find them. They're the roadmap — dated, numbered.

What's next

The v2.1.0 → v2.2.0 backlog is already those seven issues plus the #178 drift call. The next release will be quieter on features, heavier on release plumbing: TTY detection, one source of truth for "current version", protection-aware push routing, the deprecated-hint sweep. Small releases, tight loop — and each turn, the tool knows a little better where it hurts, because we dared to use it where it counts.

French version on arcker.org.