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. A reusable GitHub Action — this was listed as out of scope originally, which was about this repository rather than about the idea: the Action is packaging rather than tooling, so it lives in its own repository.

M6 · Trust after the fact Everything about a release that isn't finished the day it ships.

• letsgo doctor — a read-only, offline diagnosis of tools and repository state.
• letsgo audit — re-checking published releases against today's vulnerability database, with results appended to audit.json on the release.
• The checksum database cross-check — sum.golang.org checked against the source archive before any asset is attached, as a feature you can disable or require.
• Feature toggles — disable/require, the catalogue, and letsgo features, which the other M6–M8 work is built on.
• Prerelease channels and letsgo promote — RC tags, foo@next, floating Docker tags, update --channel, and promoting an RC to stable from the CLI or the GitHub UI.
• The "what shipped" section in release notes, and letsgo diff --format md|json.

M7 · Scale and editors Letting letsgo work on more than one machine and more than one module.

• Monorepo releases — scoped tags, the module directive, and a release title that names the module.
• Global config and the plugin store — config.mod, the directive set, flag-over-env-over-global-over-default precedence, and a content-addressed plugin store so two repositories can pin two versions of one plugin on one machine.
• Editor support — letsgo lsp, fmt -, --json output everywhere a tool needs it, and the letsgo-vscode extension.
• Plugin-aware core — the public SDK, letsgo/manifest, first-party plugins publishing their own tap files, and letsgo plugin install replacing the curl | tar recipe.

M8 · Reviewable releases plan and apply — a saved, digest-only plan that apply rebuilds and checks itself against before any write, so a release can be agreed to before it happens and an approval gate can sit between the two. Yank plans. plan --format md for a job summary. The exported letsgo/plan package and the letsgo-tfplan companion for tools that already read Terraform plans.

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.

M8's plan/apply work has been promoted to a stable release, and the VS Code extension is published to the Marketplace and Open VSX — both install exactly as described on Editor-Support and Plan-Apply.

Questions still open

• Should the extension prefer a repository-pinned letsgo version — a letsgo line in letsgo.mod, or whatever letsgo-action's workflow pins — over whatever is on PATH? The version shapes the archive layout, so a mismatch shows a plan CI would not produce.
• Own activity-bar icon, or a section in the Explorer? The module view is a section in the Explorer today; it earns its own container only if a monorepo with enough modules makes that section feel cramped.
• Snapshot version scheme. <last-tag>-next+<short-sha> needs to sort correctly under semver against both its neighbours.

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. Global config is the one addition that cuts the other way on purpose — it exists because machine-specific settings had nowhere honest to go but letsgo.mod, and it earns its place by being checked, not just documented: nothing that changes a release is allowed in it.

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.