dist.town

Releases can now say where they came from — and this one does.

Source linking

A release can pin the git commit and annotated tag it was cut from, right in the immutable record. publish --tag v0.3.0 reads both hashes from your local checkout; since git is content-addressed, the tag object hash transitively pins the entire source tree. Names are labels, hashes are truth: force-moving a tag never moves a published claim.

Set your repository once with the new disttown project set --source, and every release inherits it. When the source is a record in your own atproto repo — a Tangled repository — the association is signed by the same key as the release itself, and release pages badge it same-repo. This is honest verification: it proves association, not build provenance.

Tangled artifacts are first-class

If your CI uploads artifacts to Tangled, dist.town now treats them as locations rather than rivals:

• At publish time, tag-matched Tangled artifacts are offered for attachment (--attach-tangled for CI). The CLI downloads and hashes every blob locally — each digest in your release is your own measurement, never the forge's claim.
• Afterward, any Tangled upload whose bytes match a declared digest becomes an additional verified download location, including for releases published before the upload existed.
• Uploads that match nothing appear under an explicit "not in the record" caveat — visible, and honestly unverified.

Windows builds

This is the first release with Windows artifacts (amd64 and arm64, as zip archives), alongside Linux and macOS. The CLI is pure Go, so the whole matrix cross-compiles from one machine — tools/dist.sh in the repo is the two-line recipe. disttown --version now exists, stamped at build time.

Also

• Release pages show the source claim in the record rail: repo, tag, and commit, with copy-to-clipboard hashes.
• project set updates a project's display name, description, source, and website — only the flags you pass change.

The release that renamed itself: disttown now lives at dist-town/cli, published under the nested project name this version introduces. The old name remains a permanent alias — every existing URL keeps resolving.

Nested projects

• Project names are now paths: dist-town/cli on the command line and in URLs, dist-town:cli in the record key. Flat names remain valid — nesting is never required.
• Hierarchy lives in the name itself: no new lexicon, no parent field, and parentage derives by prefix. An umbrella page lists its children automatically.
• disttown project create writes a bare project record (umbrellas), and disttown project rename performs the alias dance atomically: successor created, old record marked renamedTo, history staying exactly where it happened.

Changelogs

• disttown changelog set <version> attaches release notes to any published release — including ones published before this command existed. Notes are plain site.standard.document records carrying at.markpub.markdown content with a derived plaintext fallback, so they render in any standard.site reader.
• Re-running the command edits the existing document in place rather than shadowing it.
• disttown publish --notes <file> lands the notes in the same atomic commit as the release. These very notes shipped that way.

Housekeeping

• OAuth sessions gain the site.standard.document scope; cached sessions need one disttown login re-run before authoring changelogs.
• --project accepts both the URL form (dist-town/cli) and the record-key form (dist-town:cli) everywhere.