Roadmap

Roadmap

M0 · Foundation Config parser, discovery, target matrix, deterministic archive writers, SHA256SUMS, letsgo build, plan --explain.

Plus the reproducibility test suite — same commit built twice on one machine, then built on Linux and macOS runners and compared byte for byte. This is the project's go/no-go gate. If cross-machine reproduction can't be made to work, verify can't ship, and without verify this is just a smaller GoReleaser. We find that out first, before building anything on top of it.

M1 · The release path letsgo plan with configuration gates and the smoke test. Changelog. GitHub release creation and asset upload with resume. Manifest. Stable source archive. Module proxy warm-up. --snapshot. letsgo release.

M2 · Verification letsgo verify. OIDC provenance attestation. Build cache. The govulncheck and apidiff gates, plus the API-derived changelog section that falls out of the latter.

M3 · Adoption A migration guide rather than a converter. letsgo diff, size budgets, a generated install.sh that carries its own digests, and Homebrew tap generation pointed at our own reproducible archives.

At the end of M3 letsgo can replace GoReleaser for the repos it targets, and does several things GoReleaser cannot.

M4 · Container images Multi-arch OCI images built from the binaries we already have: a deterministic tar layer, a JSON config, and a push over the registry API. No daemon, no buildx, no Dockerfile. The image digest goes in the manifest, so verify covers it exactly as it covers an archive. This reverses a non-goal, which is explained in Design.

M5 · Shipped letsgo yank — automating Go's retract directive, including the part people get wrong, that a retraction only takes effect once published in a later tag. A reproducible CycloneDX SBOM. An embeddable selfupdate package, so any binary released with letsgo gets verified self-update for free — and letsgo update, which is that package pointed at letsgo.

Also shipped: a reusable GitHub Action. It was listed here as out of scope, which was about this repository rather than about the idea: the Action is packaging rather than tooling, so it lives in its own repository, versioned separately from the binary it runs.

Still not here: GitLab and Gitea. The forge interface exists so a second forge is an addition rather than a rewrite, but nothing has been built against it yet.

Questions still open

• Config format. letsgo.mod in go.mod syntax is the recommendation, with five alternatives considered and rejected. Cheap to change now, expensive later.
• Is the API-compatibility gate default-on? It's the most opinionated check in the tool and the most likely to irritate before we know its false-positive rate. Default-on with --allow-breaking is proposed; default-warn for the first release is defensible.
• Snapshot version scheme. <last-tag>-next+<short-sha> needs to sort correctly under semver against both its neighbours.
• Does letsgo build require a tag, or imply snapshot semantics on an untagged HEAD? Leaning toward the latter.

How we'd like this to change

Two commitments that constrain future features more than they enable them:

The config surface should shrink over time, not grow. If a repo needs a new config option, the first question is whether we could have inferred it. A growing config file is the failure mode we're specifically trying to avoid, and every option added is a small admission that inference wasn't good enough.

New gates are welcome; new publishing targets mostly aren't. Checks that catch a class of mistake Go lets you make silently are exactly on-thesis. Another packaging backend is how a focused tool becomes an unfocused one — and GoReleaser already occupies that ground well.